Summary
BuilderPal uses a directional flow model to handle work between general contractors and subcontractors. Actions flow downstream when work is assigned and flow upstream when updates, responses, and completion move back to the GC—without transferring ownership or exposing internal work.
Why It Matters
The problem this model solves
GCs and subcontractors do not operate as a single team
Not all work or communication should be visible across companies
Assignments often need to cross company boundaries without breaking accountability
Without clear direction, projects either become too restrictive or too exposed.
The benefit to contractors
Clear responsibility across company lines
Clean handoffs without duplicating work
No accidental access to internal Actions
A shared source of truth for work that involves both sides
The flow model allows collaboration without collapsing company boundaries.
How Action Flow Works
Actions always belong to the project where they are created. They do not move between projects or change ownership.
Instead, BuilderPal controls how Actions are shared and responded to between companies.
Downstream Flow (GC → Sub)
Downstream flow happens when a general contractor assigns an Action to a subcontractor.
Common examples include:
Assigning Scheduled Work
Issuing Punch List items
Assigning RFIs or Site Instructions
In a downstream flow:
The Action remains owned by the GC project
The subcontractor sees the full Action
Communication, files, and updates happen inside that same Action
This is the primary way GCs coordinate work with subs.
Upstream Flow (Sub → GC)
Upstream flow happens when a subcontractor responds or submits information inside an Action assigned by the GC.
This can include:
Completing assigned work
Uploading files or photos
Responding to RFIs
Updating required information
Marking work complete
Although subcontractors cannot assign Actions to GC users, their updates flow upstream through the same Action. The GC is notified and sees the response in context.
Upstream flow is about information and progress moving back, not ownership changing.
Why Actions Don’t Move Between Projects
Actions never transfer between GC and subcontractor projects.
Instead:
One Action acts as the shared record
Visibility is controlled by assignment and participation
Permissions are enforced by role and project ownership
This prevents duplicate Actions, lost context, and conflicting versions of work.
What This Means in Practice
GCs assign work downstream
Subs respond upstream within the same Action
Internal planning stays internal
Shared work stays shared
Responsibility moves, but ownership stays clear.
Next Steps
Learn how permissions affect what each role can edit
Explore Action types commonly used across companies
Understand how communication and notifications work inside Actions
