Roles and permissions

Access is checked on the server for every read and every write, never only in the interface, so what a role cannot do here it cannot do at all — not just cannot see a button for.

Project roles

Four roles apply within a single project, each including everything the one before it can do:

Viewer

Read-only: the register, cost lines, WBS, simulation results, reports and documents.

QS Estimator

Everything a Viewer can do, plus editing risks and cost lines, assigning WBS codes, viewing the rates library, exporting reports as PDF, and editing documents.

Risk Manager

Everything a QS Estimator can do, plus deleting and importing risks, accepting or rejecting AI mitigation assessments, running simulations, editing the schedule, generating reports, and deleting documents.

Admin

Everything a Risk Manager can do, plus editing and publishing rates, project settings, and managing project members.

Company roles

Three roles apply across the whole company, independent of any one project:

Member

No company-wide permissions on their own. What they can do depends entirely on their role on each project they belong to.

Org Admin

Creates and archives projects, invites and manages members, edits the shared reference data and rate library, and views the company audit log. A company admin also administers every project as if they held the Admin project role there, even one they have not been individually added to.

Owner

Everything an Org Admin can do, plus editing company-wide settings.

Capability matrix

The permissions most people ask about by name:

This is a summary, not the full list. The system tracks a longer set of finer-grained permissions internally; the admin invitation screen and the member overrides panel only surface the ones people actually ask for by name, to keep the settings page short.

Per-person overrides

A single permission can be granted to, or withheld from, one named person without changing their role. This is for the exception, not the rule: a Viewer who needs to export one report, or a programme controls lead who needs to see documents across every project without being made a company admin.

Overrides can be set at company level or at project level, and the order they resolve in is fixed:

1. An explicit grant or denial on this project, for this person
2. An explicit grant or denial at company level, for this person
3. The project role a company admin is implicitly given (Admin)
4. The default for the person’s project role
5. The default for the person’s company role

A denial at a narrower scope always beats a grant at a wider one. In practice this means: if someone should not be able to do something, deny it on the project directly, and no company-level grant or admin status will override that denial for them.

Inviting and managing members

From Project Admin or the company settings page, choose Invite Team Members. For each invitation, set:

• Their email address.
• Their company role (Member, Org Admin, or Owner — the last two only available if you hold that authority yourself).
• A project role for one or more specific projects, if they should have access beyond whatever their company role already grants.

The invitation link is shown once, at the moment it is created, and is not stored anywhere in readable form. Copy it to the person directly; if it is lost, resend the invitation rather than searching for the old link, which mints a new link and invalidates the old one.