How to Manage Multi-Company Projects Without Losing Control Over Access & Permissions
Six companies, one project, one set of files that shouldn't all see each other's work — here's the full playbook for structuring access without oversharing, without guest-board gymnastics, and without rebuilding your permission setup every time scope changes.
Open any real construction project and count the companies on it. An architecture firm that owns the project. A structural consultant. An MEP contractor. A civil contractor. An interior designer. And the client, who wants visibility without editing rights. That's six separate organisations working on one project, each of whom should see and touch a different slice of it — and each of whom has a legitimate business reason not to see the others' internal work.
Most project management tools were never built for that. They assume one team, on one board, working on one shared set of tasks — which is a fine model for a marketing sprint and a genuinely bad fit for a construction project with contractual boundaries between companies. Firms end up solving this with workarounds: guest boards, duplicated projects per contractor, spreadsheets tracking "who can see what" on the side, or just giving everyone the same access and hoping nobody touches the wrong file. None of those are actually access control — they're damage limitation, and they usually fail quietly, not loudly, which is worse.
This guide covers how multi-company access should actually work: the model, the specific actions that need scoping, the mistakes firms make setting it up, and a full walkthrough of a real project with three subcontractors on it.
Why "One Team, One Board" Breaks on Real Projects
The failure mode is always the same. You invite Contractor A to the project board so they can see their tasks. To do that in a flat-permission tool, you either give them visibility into the entire board — including the client's budget discussion and Contractor B's unrelated tasks — or you spend hours building a segregated board-within-a-board structure using filters, custom views, and naming conventions. That structure holds together right up until the project scope changes, a new consultant joins mid-project, or someone needs to be reassigned from one company's scope to another's. Then you're rebuilding it, usually under time pressure, usually while the project is still live.
The underlying issue is that flat tools have exactly one axis of control: who's on the board. Construction projects need two: which company someone belongs to, and what they're allowed to do within that company's scope on this specific project. Without both axes, you're always trading off between oversharing and administrative overhead — and most firms end up doing a bit of both, which is the worst combination: sensitive data leaks between companies, and someone is still manually managing a spreadsheet of who's allowed to see what.
There's a second, quieter cost too: audit trail collapse. When everyone shares one flat access level, you lose the ability to answer "who could have approved this?" or "who had access to this drawing when it leaked to a competing bidder?" With genuinely scoped access, the answer to both questions is a short, specific list — not "everyone on the board."
Related Link
The Role Hierarchy That Actually Maps to a Construction Project
Wallxy's permission model works on two layers: a permission level (admin, moderator, contributor, or viewer) that governs what someone can do, and an origin-owner flag that marks the company that actually owns the project. On top of that, a company brought onto the project by someone other than the owner is tracked as a distinct associate company, with its own scoped team.
Put together, that gives you the roles that matter day-to-day:
Project owner — the company that owns the project. The only role that can reassign which company is responsible for a given scope of work.
Admin / moderator-level roles (on the owner's side or an assigned company) — can manage their own company's team, assign work within their scope, and move drawings through review states.
Contributor-level team members — can upload and work within their assigned scope, without approval or reassignment rights.
Associate company member — a member of a company brought onto the project by someone other than the owner (common when a contractor sub-hires their own team). Scoped to their own company only.
Viewer — read-only access, typically the client's role when they want visibility without edit rights.
The critical property of this model is that each company only ever sees and acts within its own assigned scope, not the whole project. Contractor A's team doesn't see Contractor B's internal task breakdown. The client sees progress without being able to edit drawings. And crucially, nobody had to hand-build a segregated view to get there — scope is the default, not a workaround bolted onto a flat system.
Where This Differs From "Guest Access" in Generic Tools
Most generic project management tools handle outside collaborators with some version of a "guest" seat — a limited-permission user added to a specific board or a handful of items. It sounds similar to scoped access on the surface, but the two models solve different problems.
A guest seat is typically an exception carved out of a flat structure: the default is "everyone on this board sees everything," and a guest is a manually restricted deviation from that default, usually configured board-by-board or item-by-item. That means:
Every new external collaborator requires manual setup, not automatic scoping.
Guest permissions are usually visibility-based (can they see this board or not), not action-based (can they upload, can they approve, can they reassign).
There's no concept of a company owning a scope of work — a guest is an individual exception, so if three people from Contractor A need the same restricted access, you're configuring it three times.
When the project's structure changes, guest permissions don't automatically follow — someone has to go back and manually update who's a guest on what.
A project-scoped role model inverts the default: scope is structural, not an exception. A company is assigned a piece of work once, and every person on that company's team inherits the correct scope automatically — including people added later, mid-project, without any manual reconfiguration.
Related Link
The Dual-Identity Problem Almost Nobody Solves Correctly
Here's a scenario that breaks most permission systems: you own Firm A, and you're also a team member on a project owned by Firm B, working as their structural consultant. You're the same person, but your authority should be completely different in each context — full control on your own firm's projects, scoped contributor access on Firm B's.
Systems that assign permissions to a person get this wrong constantly, because a single global role can't represent two different levels of authority for the same individual. Wallxy computes permissions per project, per company context — not as a single global role stored on the user account. Log into Firm B's project as their consultant, and you get exactly the access that role implies there — regardless of the fact that you have full owner rights elsewhere. Switch to your own Firm A workspace, and your full authority is back. There's no manual toggling and no risk of a permission from one context leaking into another.
This matters more than it sounds like it should, because the alternative — accidentally carrying owner-level access into a project you're just consulting on — is exactly the kind of privilege escalation that causes real disputes about who approved what. It's also increasingly common as the industry gets more networked: consultants who run their own small practice while also working project-to-project on other firms' jobs are the norm, not the exception, so a permission model that can't handle this dual identity is solving yesterday's org chart.
Scoping Permissions to Specific Actions, Not Just "Access"
Access control that only asks "can this person see the project" is too coarse for construction. The actions that matter are specific, and each one needs its own rule:
Uploading a drawing sits at contributor level or above — a contractor's team can submit their own drawings without needing approval-level access.
Approving or requesting revisions on a drawing is restricted to admin- and moderator-level roles on the project. This keeps approval authority with senior roles rather than every contributor, so submission and sign-off stay meaningfully separated — even though the check isn't narrowed to the owner alone.
Assigning or reassigning a task to a person is available to the project owner or an admin/moderator-level role within their own company's scope — a subcontractor's admin can shuffle their own team's tasks, but can't reassign work belonging to a different company.
Reassigning which company owns a piece of work entirely is the one action reserved exclusively for the project owner, since it changes contractual responsibility, not just task allocation.
Viewing project-wide discussions and team lists is itself gated — someone without an active role on the project shouldn't be able to see who else is working on it, let alone what they're discussing.
Splitting access into this many distinct actions sounds like more complexity, but it's actually what removes complexity from day-to-day use — nobody needs to think about "who can see what," because visibility follows naturally from what someone is actually allowed to do.
Common Mistakes Firms Make When Setting This Up
Even with the right tooling, a handful of habits from the spreadsheet-and-email era tend to carry over and quietly undermine the model:
Making everyone admin-level "to keep things simple." This collapses the hierarchy back toward flat access — the one thing the model exists to avoid.
Adding a contractor's whole team as individual guests instead of assigning the company as a scope. This means every new hire on the contractor's side needs manual setup, and nothing updates automatically when their team changes.
Giving the client edit access "just for this one change." Once a client can edit, the approval trail stops being reliable — you lose the ability to say definitively who changed what.
Forgetting to downgrade access when a company's role on the project ends. If a consultant's contract wraps up, their scoped access should end with it, not linger indefinitely.
Using one person's login for a whole company's team to avoid setting up individual accounts. This destroys the audit trail entirely — there's no way to tell which of five people on-site actually uploaded or approved something.
A Practical Setup: Architect Managing Three Subcontractors on One Site
Take a concrete case. Your architecture firm owns the project. You bring on a civil contractor, an MEP contractor, and an interior consultant, each running their own crew.
Step 1 — Assign each company to its scope of work. As project owner, assign the civil work to Contractor A, MEP to Contractor B, interiors to Consultant C. Reassigning which company holds a scope is a project-owner-only action, so it always traces back to you.
Step 2 — Let each company manage its own team. Contractor A's admin adds their site supervisor and two crew leads, and can reassign tasks among them — but has no visibility into Contractor B's task breakdown or the client's cost discussions.
Step 3 — Route drawings through the review lane, not email. When Contractor A submits a revised drawing, it moves into an "Under Review" state. Admin- or moderator-level roles on the project can move it to "Approved" or send it back as "Revision Required" — keeping approval with senior roles rather than every contributor, so there's a clear, traceable sign-off instead of an email thread.
Step 4 — Give the client viewer access. They see project progress, drawing status, and shared updates, without the ability to edit anything or see internal company-to-company task detail.
Step 5 — Handle a mid-project change without rebuilding anything. If Consultant C brings in their own specialist as an associate company member partway through, they're scoped exactly like Consultant C's original team — no board restructuring required.
Step 6 — Wind down access cleanly when a company's scope ends. Once Contractor A's civil work is signed off and complete, downgrade or remove their active access rather than leaving it live for the rest of the project.
None of these steps require constructing a custom permission matrix by hand. They fall out of the role hierarchy automatically.
Related Link
What Changes When a Company's Scope Shifts Mid-Project
Construction projects change scope constantly — a contractor gets replaced, a consultant's role expands, a company is brought in late. In a flat-permission tool, this usually means manually rebuilding whatever segregation you'd set up. In a project-scoped role model, reassigning a company's scope is a single action by the project owner, and every downstream permission — who can upload, who can be assigned tasks, who can be seen by whom — updates with it. The structure doesn't need to be rebuilt because it was never hard-coded around who happened to be on the project at the start.
This is the real test of whether a permission model scales with a real project: not how it looks on day one with a clean team list, but how much manual work it takes to keep it correct on day ninety, after two contractor changes, one scope expansion, and a client who suddenly wants their site engineer added as a viewer.
Frequently Asked Questions
Can a subcontractor's team see other subcontractors' tasks on the same project?
No. Each company's team is scoped to its own assigned work. Visibility doesn't extend across companies unless the project owner explicitly grants it.
What happens if I own one company but I'm just a contributor on another company's project?
Your permissions are calculated per project, per company context — not as one global role on your account. You get the correct, separate access level in each context, so your ownership rights on one project never carry into a project where you're just a team member.
Who has the final say on approving a drawing?
Admin- and moderator-level roles on the project. Upload rights sit at contributor level, so submission and approval stay separated — just not narrowed down to a single owner-only gate.
Can I reassign which company is responsible for a task mid-project?
Yes — that action is reserved for the project owner, since it changes which company holds contractual responsibility for that scope of work.
Does the client get full project access, or just visibility?
Clients are typically set up as viewers — they can track progress and see shared updates without editing rights or visibility into internal company-to-company task detail.
What if a contractor brings in their own sub-hired team?
They can be added as associate company members, scoped the same way as the contractor's original team, without requiring the project owner to rebuild any part of the structure.
How is this different from just adding people as "guests" like in generic tools?
Guest access in flat tools is usually a manual, per-person exception to a shared default. Scoped access assigns a company to a piece of work once, and every person on that company's team inherits the correct scope automatically — including people added later.
What's the biggest mistake firms make when setting up multi-company access?
Making everyone admin-level "to keep things simple." It collapses the hierarchy and defeats the purpose of scoped access in the first place.
What happens to a company's access once their scope of work is finished?
Access should be downgraded or removed once their contracted scope is complete — leaving it live for the remainder of the project is one of the more common oversights firms make.
Related Link
No Wallxy comments yet
Be the first to share your thoughts on this article!