How Do You Manage a Multi-Company Project Without Losing Control Over Access?
An architect, a contractor, a consultant, and a supplier on one project — all different companies, all needing different access. Here's how that actually gets managed without either locking everyone out or handing out access nobody should have.
How do you manage a multi-company project without losing control over access?
Most real construction projects aren't single-company affairs. An architecture firm designs it, a separate contracting company builds it, a consultant reviews structural or MEP details, and a supplier fulfills material orders — four or more distinct companies, all needing to touch the same project, none of them needing the same access as the others. Getting this wrong in either direction is a real problem: too permissive, and any company can reshape a project it doesn't own; too restrictive, and every company is stuck emailing files instead of contributing directly.
The core question every multi-company project has to answer
Who has final authority — not just "who's involved," but specifically who can approve, who can reassign, and who can restructure. On most real projects, the answer is clear in practice: the party who originated the project, holds the client relationship, and carries ultimate responsibility. The failure mode isn't usually disagreement about who that is — it's that the software managing the project doesn't actually enforce it, so the answer ends up depending on who happens to have admin-level access, which isn't always the same person.
How this works structurally
A useful way to think about it is a clear precedence order for who can do what, regardless of which company a person belongs to:
Project owner — the originating company, holding structural, review, and approval authority
Assigned company admin — the admin of a company brought onto the project (a contractor or consultant firm, for example) holding authority within their own company's scope of work, not the whole project
Project team member — a person contributing directly, scoped to their assigned tasks
Associate company member — someone from a company connected to the project in a more limited capacity
Viewer — read-only, typically a client or stakeholder
The critical rule underneath all of this: an assigned company can submit and update its own work, but only the project owner reviews, approves, or rejects — even on work that company submitted itself. That single rule is what prevents the most common failure mode of multi-company projects: a contractor approving their own change order, or a consultant signing off on their own calculation with no independent check.
The dual-identity problem, and why it matters
A specific edge case worth understanding: the same person can simultaneously own Company A and be a team member of Company B on a different project. If that person is working across both relationships, their actual authority has to be computed based on which specific action they're taking and in which context — not just "which workspace card did they click." A permission system that only checks workspace type, rather than the specific action being taken, can accidentally let someone use their Company A ownership to influence something they only have Company B's limited access to. Getting this right means every permission check has to be evaluated against the actual action, not assumed from whichever identity happens to be active.
Related Link
What this looks like for each role practically
The project owner sees everything, approves everything, and is the only party who can reassign a task's origin company or resolve a review
An assigned company's admin can manage their own company's people and submissions within the project, but can't touch another company's scope or override the project owner's review authority
A contributor (an individual on any assigned company) can submit and update their own work, without any structural or team-management rights
A client or stakeholder sees the live project as a Viewer, with no edit rights at all, regardless of which company they're technically associated with
Why this matters more as a project gets bigger
A two-company project can often muddle through informal norms — everyone remembers who's supposed to approve what. A five- or six-company project, with associate companies, sub-consultants, and suppliers layered in, can't rely on memory. The structure needs to be explicit and enforced, or the informal norm eventually breaks the first time someone new joins who doesn't already know the unwritten rules.
Getting started — a short checklist
Identify your project's actual owner explicitly — not by convention, by structure
Check whether any assigned company currently has more access than their own scope of work requires
Confirm review and approval authority sits with one clear party, not distributed informally across whoever happens to weigh in
If any team member is dual-affiliated (owns one company, works for another), make sure their access is evaluated per action, not per workspace
FAQ
Can an assigned company ever get approval authority on a project they don't own?
Not by default — approval and review authority stays with the project owner, even on work an assigned company submitted itself.
What happens if the same person is an owner on one project and a team member on another?
Their access is computed based on the specific action and project context, not carried over from their role elsewhere.
Does a supplier or consultant need full team-member access to contribute?
No — Contributor-level access is typically enough to submit and update their own work without broader project or team management rights.
Can a client accidentally get edit access through a company relationship?
No — Viewer access is read-only regardless of any company affiliation; it doesn't inherit edit rights from elsewhere.
Related Link
No Wallxy comments yet
Be the first to share your thoughts on this article!