How ConstructFlow is organized
ConstructFlow is built around a single tenant — your Consultant Office. Everything else (clients, contractors, subcontractors, people, projects, permissions) lives under it. This page walks through the full flow so the system stops feeling messy.
One tenant = one Consultant Office
The consultant owns the system. Only the consultant can create organizations, invite people, start projects and grant authorities. Everyone else is a guest inside that tenant.
Super-admin of the tenant. Manages orgs, projects, roles and the ACL matrix.
Clients, main contractors and their subcontractors. Each org has its own profile and people.
Members of an organization. They get access to projects via project membership.
How things nest
Mental model — read it once and the rest of the app makes sense.
Consultant Office (tenant — you)
│
├── Organizations
│ ├── Client → has Client Reps
│ ├── Main Contractor → has PM, QA/QC, Doc Controllers
│ │ └── Subcontractors (Electrical, HVAC, ELV, Civil…)
│ └── …
│
├── People (belong to an organization)
│
└── Projects
├── 1 Client (party)
├── 1 Main Contractor (party)
├── N Subcontractors (parties)
├── Members (people assigned with a project role)
└── Authorities (per-org ACL overrides)From zero to a running project
Six steps. Do them once per project.
- 01
Create the client organization
Add the project owner (e.g. Qatari Diar). Fill profile, CR number, address and primary contact.
Organizations - 02
Add the main contractor
Create the contractor org and its subcontractor children (Electrical, HVAC, etc.). Subs are nested under their contractor.
Organizations - 03
Invite people
Add people inside each organization (PM, reviewers, client reps, trade leads). They are not on any project yet.
People directory - 04
Start a project
Pick 1 client + 1 main contractor + the subs working on it. Assign a consultant lead. The project now exists.
Projects - 05
Assign people to the project
From the project's Team tab, pick which people from each org join, and give them a project role (can differ from their org default).
Projects - 06
Tune authorities
Open the project's Authorities tab and override per-org permissions where the default role template isn't enough.
Projects
How access is resolved
Every action a person tries — view a submittal, approve an RFI, export a report — passes through the same 4-step resolver.
Specific allow/deny on this person for this project. Highest priority.
Authority set on the org for this project (Authorities tab).
Default permissions for that role (editable in Settings → Roles).
If nothing matched, the action is blocked.
Modules × Actions: 12 modules (Submittals, RFIs, NCRs, Drawings, Inspections, Documents, Reports, Punch List, Orgs, People, Projects, Settings) × 8 actions (view, create, edit, review, approve, close, export, delete).
Default role templates
Start here. Override only when a specific org or person needs different access on a specific project.
Use the "Acting as" switcher
In the top header, swap between a consultant, a contractor PM, a client rep, etc. The whole UI re-evaluates — buttons disappear, tabs lock, exports hide. This is how you verify a role is correctly scoped before going live.