Skip to main content
The platform uses a role-based access control (RBAC) model. Every member has a workspace-level role, and external (field-team) roles can be further scoped to specific projects with per-project overrides.

​
Built-in roles

Roles fall into two groups: workspace roles for your internal team, and external roles for field collaborators who should only see the projects they are working on.

​
Workspace roles

Owner

Exclusive control over the workspace itself. Owners can do everything an Admin can do, plus transfer workspace ownership, permanently delete the workspace, and export workspace data. There is exactly one Owner per workspace.

Admin

Full access to settings, billing, all projects, and member management. Admins cannot transfer ownership, delete the workspace, or export workspace data.

Member

Can create projects, manage content, and invite collaborators within their projects. Cannot access billing or workspace settings.

Viewer

Read-only access to projects they are explicitly added to. Cannot create, edit, or delete content.

​
External roles

External roles are designed for contractors and other field collaborators. They never see the full workspace — they only see the projects they are explicitly assigned to.

Consultant

Read and write access to requirements, sustainability, and the project directory. Can act on approval steps assigned to them. Cannot see Approval Routing configuration.

Contractor

Read access to requirements, sustainability, and directory. Can act on approval steps. No access to Contractor Performance or Progress Report analytics.

Subcontractor

Limited field access. On Issues, Site Diary, and Punch List, Subcontractors can only edit or delete items they themselves created (own-item scope). Cannot trigger QA actions, early-warning flag actions, or warning-threshold changes.

Supplier

Directory read access only. Designed for material suppliers who need to look up contacts but should not see project data.
Subcontractor own-item access also applies to bulk-update and status-transition endpoints. A Subcontractor cannot, for example, bulk-close a list of issues that contains issues authored by another user — the entire batch is rejected.

​
Permission strings

Each role is defined by a set of granular permission strings. Workspace settings used to share two generic strings (settings:read and settings:write); those have been replaced with dedicated strings so roles can be scoped precisely:
AreaPermission strings
Project templatesproject-templates:read, project-templates:write
Custom fieldscustom-fields:read, custom-fields:write
Workflow rulesworkflow-rules:read, workflow-rules:write
Approvalsapprovals:manage (configure routing), approvals:act (approve/reject)
Audit logaudit:read
Integrations & webhooksintegrations:manage
Email templatesemail-templates:read, email-templates:write
Data exportdata:export (Owner only)
Custom roles can be built from any combination of these strings.

​
Per-project role overrides

A member’s workspace role can be overridden for an individual project. This is most commonly used to give an external role a different scope on a specific project — for example, making a Contractor act as a Consultant on one job. External roles must have at least one project assignment to see any project data. Members without an override fall back to their workspace role. To assign or clear an override:
  1. Open the project and go to the Members tab.
  2. Find the member. The badge shows their effective role; an asterisk (*) indicates an override is in place.
  3. Open the role dropdown and pick a new role, or pick Workspace default to clear the override.
PATCH /api/v1/projects/{projectId}/members/{userId}/role
Content-Type: application/json

{ "role": "consultant" }
Passing "role": null removes the override and returns the member to their workspace role for that project.
Only Owners and Admins can manage project-scoped access and role overrides.

​
Role history

Every role-override change is recorded in an audit trail. Admins can review the full chronological history of who changed which role, when, and from what to what.
  • Per-project history — On the project Members tab, open a member’s row to see role-override changes scoped to that project.
  • Cross-project history — On the workspace Team page, open a member to see every role-override change for that member across every project, from one place.
Each entry shows the timestamp, the actor (the admin who made the change), the project, and the old → new role.

​
Transfer workspace ownership

Only the Owner can transfer ownership. The transfer is immediate: the new Owner gains all Owner-only capabilities, and the previous Owner is downgraded to Admin.
  1. Go to Workspace Settings → General → Danger Zone.
  2. Click Transfer ownership.
  3. Use the searchable picker to choose the new Owner. Only existing workspace members are eligible.
  4. Type the workspace name to confirm, then submit.
Both parties receive an email notification once the transfer completes.
Transfer ownership and Delete workspace (also in Danger Zone) are permanent and cannot be undone from the UI.

​
What members see when access is denied

When a member opens a page they don’t have permission for, the platform shows them why instead of redirecting silently:
  • Permission-gated routes — A destructive toast appears with the message “Access denied — You don’t have permission to view ”, and the user is redirected to the URL configured by redirectTo (usually the workspace home).
  • Portfolio Schedule — External members with project-scoped access see a blocked-state error directing them to use the per-project Schedule view. The page does not retry the request.
  • Approval Routing — Hidden from Consultants and other roles without approvals:manage. Direct navigation triggers the denied-access toast.
  • Upgrade-gated routes — If the feature requires a higher subscription tier, a toast names the feature and the required plan before redirecting.

​
Custom roles

Custom roles let you define precise permission sets for teams with non-standard access needs. Each custom role is built by selecting from the permission strings listed above. To create a custom role:
  1. Go to Settings → Roles → New role.
  2. Give the role a name and optional description.
  3. Toggle individual permissions on or off.
  4. Save and assign to members.
Custom roles are available on Business and Enterprise plans. Workspace Admins can create and manage up to 20 custom roles.