Roles & permissions

Roles & permissions is where an org admin controls what each role can do and which data each role can see. Find it in the sidebar under the Admin section of the Workspace area (it’s hidden unless you’re an org admin).

This page sets the rules by role. You assign specific people to roles somewhere else — see Assigning people to roles below.

The roles

There are seven project roles, plus a fixed Org admin:

Project manager — your team; runs the project and edits everything
Co-manager — joint-venture partner lead, same rights as a project manager
Client lead — client decision-maker; edits and approves
Consultant — designer / consultant, with read access but no writes
Viewer — read-only across the project
Client viewer — client-side read-only
Finance — read-only, but trusted to see internal and financial items

The project manager and co-manager are the project’s leads: on the Tasks page they can close tasks whichever company runs the list, as long as their role can edit tasks (it can by default).

Org admin has full access to everything and can’t be edited, so you can’t accidentally lock yourself out. It shows as an always-ticked column in the permission matrices.

The permission matrix

Two grids set what each role can do. Tick a cell to grant that role a permission; untick to remove it.

Project permissions — actions on a project’s own data (risks, issues, decisions, actions, stakeholders, settings, and so on). Each role has its own column.
Workspace permissions — workspace-wide resources (organisations, users, Slack, tracker…), governed by org membership rather than a project role. Here only reads can be granted to any member; writes stay org-admin only. Unticking a read also takes it away on every project: untick Tracker → read and no member, whatever their project role, sees a project’s tracker pages. Org admins always keep it.

Tasks have no delete cell. Deleting a task asks Project settings → write, the same as archiving one, and the task goes to the Bin, which only workspace admins see (see Deleting a task). An API token needs the projects:write scope to delete a task. Removing an item from the inbox is different: it asks Inbox / ingest → write, and it removes for good the tasks read only out of that item.

A task, risk or issue is often owned by a stakeholder. A role without Stakeholders → read is not shown which stakeholder owns it: the registers, the Tasks page, Workload, the record page and its history show “Someone you cannot see”; the knowledge graph draws no line from the work to its owner; chat counts the work without naming who holds it. The role can’t choose a stakeholder as an owner either. People always see themselves as the owner of their own work. An API token without the stakeholders:read scope is treated the same way.

This hides who owns the work, not every trace of a stakeholder. A name or email address typed into an item’s owner field is part of the item, so it can still show, and a typed email address is still matched to the stakeholder it belongs to. Generated documents, such as status reports, still name owners: they are written for everyone allowed to open them. And stakeholders can still turn up outside their own register, for example in search results.

What each role can see

Visibility is no longer set here. Every item carries a clearance level on an eight-level ladder, and each role sits on a rung of that ladder — a role sees an item when its rung is at or above the item’s level. The ladder, the role-to-rung mapping and compartment membership all live on their own page: see Clearance.

Assigning people to roles

You don’t add people here. You grant a person a role inside the project, under Settings → Team, where you add a workspace member and pick their role. This page only defines what each role means. See Create a project for how project access works, and the Glossary for the terms used here.