The role strategy that scales
with your delivery
Tying permissions to people works — until it doesn't. Staff turnover, firm replacements and multi-discipline projects expose the fragility of flat role lists. Foreman's three-level hierarchy keeps your CDE governed, auditable and effortless to change.
Why flat roles break at scale
Three scenarios every CDE manager recognises — and dreads.
The Jane Problem
Jane leaves the project. Her name is baked into 14 folder permissions across 6 disciplines. Her replacement inherits a spreadsheet — and three weeks of manual re-mapping before they can actually start work.
The Merger Problem
Two firms merge mid-programme. Both used a role called "Design Lead" — but with completely different permission sets. Reconciling them means an all-hands meeting, a new naming convention, and re-tagging hundreds of members.
The Audit Problem
An ISO 19650 auditor asks: "Who can approve electrical designs on Package 4?" With flat roles, the answer lives in someone's head. With structured roles, the CDE answers programmatically in seconds.
Three levels. Infinite clarity.
Each role is composed of exactly three dimensions — who they represent, what they do, and in which discipline.
Party
The "Who" — which organisation or contractual partyStandard Model (BS EN ISO 19650)
Uses placeholder designators you define — such as Employer, Lead Designer, Contractor — so the role structure is organisation-agnostic.
Direct Role Model
Uses descriptive names — Legal, Strategy, Finance — for teams where the function matters more than the contractual position.
Functional Role
The "What" — the action or responsibilityDescribes what the person does, independent of who they work for or which discipline they cover. You define the functional roles that reflect your project's workflows.
These are examples — you define the functional roles that suit your project's workflows.
Reviewing deliverables for compliance before they move to approval
Signing off design packages and authorising information releases
Managing transmittals, naming conventions, and distribution lists
Coordinating design outputs across teams and ensuring programme alignment
Enforcing modelling standards, clash detection, and federated model governance
Day-to-day contributors uploading drawings, schedules, and reports
Overseeing the CDE, access policies, and information exchange workflows
Cross-discipline oversight of delivery milestones and resource allocation
Discipline
The "Area of Expertise" — further breaks down each party into specialist teamsThis is where the real granularity lives. A single party — say Lead Designer — will typically have multiple specialist teams working under it: Architecture, Structure, Mechanical, Electrical, and so on. Level 3 lets you distinguish between them. Instead of one broad "Lead Designer" permission that covers everything, you can target exactly who should see, upload to, or approve within each technical area.
The same applies to any party. A Contractor might have separate teams for Highways, Drainage, and Earthworks. An Employer might split oversight across Environmental, Geotechnical, and Fire Engineering. Level 3 is what turns a flat party label into a structured, permission-ready breakdown of the real team on the ground.
Example: How Level 3 breaks down a single party
Each combination — Lead Designer–Checker–Architecture, Lead Designer–Checker–Structure, etc. — becomes its own distinct role with targeted permissions.
Not every role needs a discipline breakdown. Setting Level 3 to All serves two purposes:
No breakdown needed
Some parties or functional roles don't split by discipline. A Finance team or a Document Controller may operate across the whole project without needing per-discipline separation. "All" means the role applies project-wide — no further breakdown required.
Umbrella grouping
Even when a party does have discipline-specific roles, you can add an All role alongside them. For example, Lead Designer–Design Manager–All gives one person oversight across every Lead Designer discipline — perfect for receiving communications, running reports, or coordinating across specialist teams.
A few common discipline examples — your project can have as many or as few as needed:
Build a role in seconds
Click any option in each level to compose a structured, self-documenting role name.
Build a role — select one from each level
Party
The “Who”
Identifies the contractual party — using ISO 19650 placeholders or direct role names. You define the parties that match your programme structure.
Functional Role
The “What”
Describes what the user does in the project workflow — their responsibility, not their job title. Define the functions that matter to your delivery.
Discipline
The “Area of Expertise”
Specifies the technical specialism. Choose from 40+ built-in disciplines or define your own to match your project’s needs.
The client's environmental checker, responsible for reviewing flood risk assessments and ecological surveys before approval.
The contractor's document controller managing road geometry documents — transmittals, naming conventions, and distribution to the client.
An umbrella role spanning all Lead Designer disciplines. While each specialist team (Architecture, Structure, etc.) has its own roles, this "All" role lets the Design Manager receive communications and coordinate across every team.
Getting started with Foreman
Three steps to go from an idea to a working project matrix — connected to your Autodesk Construction Cloud projects.
Build your project matrix
Use Foreman's Project Matrix Wizard to define your parties, functional roles, and disciplines. The wizard walks you through each level, lets you pick which combinations you need, and generates a complete, validated role list — ready to download as a CSV. Learn more about the Project Matrix Wizard
What the wizard produces
Add roles to ACC
Take the generated role list and add them as admin roles in your Autodesk Construction Cloud project. These become the available roles that can be assigned to members — ensuring your ACC project speaks the same structured language as your project matrix.
In ACC Admin
Import back into Foreman
Provide the same role list to Foreman so it knows which roles exist on your project. Once imported, Foreman can use them across all its features — bulk member onboarding, access request forms, role-based folder permissions, and AI/MCP automation.
Unlocks in Foreman
Foreman is the source of truth for your role strategy. ACC holds the roles for permission assignment, but Foreman is where you design, manage, and evolve them. When your project grows or parties change, update the matrix in Foreman and sync the changes to ACC.
Why teams choose structured roles
The three-level model pays for itself from day one — here's how.
Scalability
Add 500 members to a new project phase — each inherits the right permissions instantly through their composed role, not individual assignment.
Auditability
Answer "who can approve structural designs?" in seconds — filter by L2 = Approver, L3 = Structure. No spreadsheets, no guesswork.
ISO 19650 Alignment
The party–function–discipline model maps directly to the standard's information management framework. Compliance is structural, not cosmetic.
Automation Enablement
Because roles follow a predictable structure, Foreman can automate what would otherwise be manual work — bulk-assigning members by party or discipline, re-mapping roles when firms change, running compliance checks, and driving AI/MCP workflows that understand exactly who does what.
Folder Structure Logic
The Project Matrix Wizard also helps you set up folder structure logic in ACC. Define how folders map to parties and disciplines, so the right teams get access to the right areas — and Foreman validates the structure before it's applied.
Future-Proofing
Firms change, teams rotate, disciplines expand. The role structure absorbs change — swap the party mapping and every permission follows automatically.
Governance & Consistency
Every project on the programme uses the same vocabulary. "Contractor-Approver-Civils" means exactly the same thing on Project A as on Project Z.
Repeatable Templates
Define a project matrix once and reuse it across projects. New projects inherit a proven structure — complete with matching folder templates and permission sets — so setup takes minutes instead of days.
Smarter Onboarding
When adding members, Foreman presents only valid role combinations from your matrix. No guesswork, no typos, no invalid assignments — just pick the party, function, and discipline and the member is provisioned with the correct ACC role.
Two models, one framework
Choose the Level 1 model that fits your project governance — or mix them.
Standard Model
Follows BS EN ISO 19650 with abstract party codes. The role exists independently of which firm holds the appointment — making party swaps zero-effort.
Direct Role Model
Uses descriptive, human-readable party names. Best for teams where the function or department matters more than the contractual appointment.
Example: Project Party Matrix (Standard Model)
| Party Code | Description | Current Firm | Scope |
|---|---|---|---|
| Employer | Client / Asset Owner | Meridian Infrastructure | Overall asset owner |
| Lead Designer | Lead Appointed Party | Pinnacle Design | Multi-discipline design coordination |
| Contractor | Principal Contractor | Bridgeway Engineering | Civils & drainage construction |
| Subconsultant | Specialist Subconsultant | Clearwater Consulting | Environmental & flood risk |
Ready to bring structure to your CDE?
Start with a free trial — no credit card required. Import your existing roles or build from scratch with the Role Wizard.