How to set up user roles and permissions for a construction team

Access is the quietest risk a construction company carries. Nobody notices that a former superintendent still has a login, that a subcontractor's account survived the job it was created for, or that four people can approve a commitment when the policy says two. Nothing breaks — until an audit, a claim, or a payment dispute asks who was allowed to do what, and when.

This lesson is about user access as an ongoing discipline: how people are added, how roles are designed, how duties are separated, how access is reviewed and removed, and how every one of those changes leaves a record. The organization setup lesson covers the wider structure a company stands up once — profile, workspaces, workflow standards. This one stays on the part you administer every week.

Learning objectives

• Run an invitation-only onboarding process where access is always granted deliberately.
• Manage the full user lifecycle: invited, active, disabled — and why removal is the wrong default.
• Design a role catalog small enough to be understood and enforced.
• Apply least privilege without slowing the work down.
• Separate financial approval, procurement and administration so no one person closes a loop.
• Scope external participants to their own commitments and compliance only.
• Review access on a schedule and on events, and prove every change afterwards.

The user lifecycle, not the user list

A user list is a snapshot. A lifecycle is what actually needs governing, and it has three states worth naming.

Invited

The person has been authorized but has not yet activated. The role was chosen at the moment of invitation, so there is never an interval where an account exists without a defined permission set. Pending invitations should expire on their own; an invitation that stays open for months is an unattended door.

Active

The person is working. Their role should still be the role their work requires — not the role they needed during one busy month two years ago. Role drift is the single most common finding in an access review.

Disabled

Access has ended, and the historical record has not. Disabling is the correct end state for departures, contract completion, and inactive accounts, because everything the person authored stays attributed. Deletion destroys the provenance that makes the rest of the record defensible.

Why invitation-only onboarding matters

Open sign-up seems harmless in construction software because most joiners are legitimate. The problem is not the joiners; it is that the access decision moves from an administrator to whoever has the link. Invitation-only onboarding keeps three properties that self-service loses.

• Every account traces back to a named person who authorized it.
• The role is decided before access exists, not corrected afterwards.
• The user list stays equal to the authorized list, which is what an access review compares against.

It also makes offboarding tractable. When you know who invited each account and why, you know which accounts should close when a project, contract or employment ends.

Designing a role catalog you can enforce

Role design fails in one of two directions. Too few roles and everyone becomes an administrator by necessity. Too many and nobody can say what any of them actually permit, so requests get approved by pattern-matching instead of policy.

A workable starting catalog

• Owner or administrator — manages users, roles and company-level configuration. Deliberately a small, named group.
• Executive — portfolio and financial visibility without transactional authority.
• Project manager — commercial ownership of assigned projects, commitments within a defined threshold.
• Superintendent or field lead — daily reports, inspections, issues and field execution.
• Project engineer — RFIs, submittals and documentation flow.
• Accounting — commitments, invoices, pay applications and payment status.
• External participant — a subcontractor or vendor scoped to their own commitments and compliance documents only.

The test for a new role

Before adding one, write down the permission it would hold that no existing role holds. If you cannot, you are describing a job title, not a role. Job titles belong in the directory; roles belong in the permission model, and the two do not need to match.

Least privilege in practice

Least privilege is often argued about in the abstract and then abandoned the first time it inconveniences someone. It survives when it is expressed as defaults rather than restrictions.

• Grant the access the work requires today; add more when the work changes, not in anticipation.
• Make elevated authority explicit and time-bound rather than permanent and forgotten.
• Keep read access generous and write access deliberate — most complaints about access are actually complaints about visibility.
• Scope by project wherever the work is project-bound, so membership on one job never implies another.
• Treat administrator rights as a duty roster, not a seniority reward.

Permissions also need to hold where it counts. Hiding a button is a user-experience choice; refusing the operation on the server is the control. Any access model that exists only in the interface is a suggestion.

Separation of duties

Separation of duties is the reason permissions are worth designing at all. Three capabilities should be able to move independently of each other.

Creating an obligation

Writing a commitment, issuing a change order, or awarding a package. This is normally a project management capability, bounded by a value threshold.

Approving an obligation

Financial approval above the threshold. It should sit with someone who did not create the obligation, and the threshold should come from company standards rather than being set per project.

Administering access

The ability to change roles and permissions. Whoever holds it can, in principle, grant themselves the other two — which is why the group is small, named, and why every change it makes is logged.

Those boundaries are only real if the system treats financial approval, procurement authority and user administration as separate capabilities. Bundled into one "administrator" flag, separation of duties becomes a policy document nobody can enforce.

External participants

Subcontractors, vendors and design partners usually need access, and they are the accounts most likely to outlive their reason for existing.

• Scope them to their own commitments, submittals and compliance documents — never the project's full commercial record.
• Tie the account's lifetime to the contract, and close it at completion rather than at the next audit.
• Keep compliance documents attached to the company record so expiry is visible without granting broader access.
• Give each person their own login; shared vendor accounts destroy attribution.

Offboarding that survives an audit

Offboarding is where access governance is actually judged. A clean process has four steps and takes minutes.

• Disable the account the day access should end — not the day the paperwork clears.
• Record a reason and an effective date so the change explains itself later.
• Reassign open responsibilities — approvals in flight, submittal reviews, unresolved issues — to a named person.
• Confirm the history remains attributed to the original author.

The same sequence applies to a role change. Someone moving from field to preconstruction should lose the access they no longer need at the same moment they gain the access they do; keeping both is how a permission model quietly stops meaning anything.

Auditability: proving it afterwards

Access control that cannot be reconstructed is access control you cannot defend. Three records make it defensible: who granted or changed each permission, when it took effect, and what the state was at any past date.

That is the same connected-record principle behind the rest of the platform — described in the operating model and in our security overview. An administrative change is an event on the record, not an edit that overwrites what was true before it.

A quarterly access review that takes an hour

• List every active account and the role it holds.
• Flag accounts with no activity in the period and confirm each is still needed.
• Confirm the administrator group is still the intended small group.
• Check that every external account maps to an open contract.
• Compare project membership against the people actually working on each job.
• Verify departures from the period are disabled, with reasons recorded.
• Record the review itself, including what was removed.

Common access-management mistakes

Administrator as a convenience

Granting full rights because a narrower role would need one more permission. The cheaper fix is to correct the role; the expensive fix is explaining, later, why six people could change company configuration.

Deleting departed users

It feels tidy and it removes the attribution that makes daily reports, approvals and change history usable as evidence.

Vendor accounts that never close

The contract completed in the spring; the login worked through the winter. Tie account lifetime to contract lifetime and this class of finding disappears.

Roles that drift with careers

Access accumulates as people move between jobs and never subtracts. Within a few years the most senior field staff hold more permissions than anyone intended.

Access reviews with no removals

A review that confirms everything is fine every quarter is not testing anything.

Where this fits

Company-level structure comes first, then the access model on top of it, then each project inherits both. If you have not defined workspaces and workflow standards yet, start with organization setup. If your access model is settled, the next decision is project-level: who is on a given job and what that job exposes to them, covered in project setup.

Frequently asked questions

Related Academy lessons

For the wider platform this access model protects, see the platform overview, how general contractors use ConstructVue, or return to the Academy hub.