Roles and permissions
The four workspace roles, the permission keys behind them, and why two people in the same workspace see different screens.
Projectri does not decide what you can do from your job title. Every screen and every API call checks a named permission key — task.create, finance.invoice.view, discussion.post — and your role is only the starting set of keys you were given. That is why "can Sam delete this project" has a real answer rather than a guess, and why your left rail can look nothing like the person's next to you.
The four roles
There are exactly four, and there is no way to create a fifth: the role is a database enum, so a new one would need a schema change. What an admin actually needs — "this person is a Member but may also see billing" — is a per-member override rather than a new role.
| Role | What it is |
|---|---|
| Admin | Runs the workspace. Holds every key through a * wildcard, plus billing, security and the admin console. |
| Member | Does the work. Creates and edits projects, tasks, documents, notes, boards and calendar entries; logs time; posts in discussions. |
| Viewer | Reads what they have been given access to and changes nothing. |
| Guest | Sees only what was explicitly shared with them. The role itself grants almost nothing; the sharing is the mechanism. |
Your role is per workspace, not per account. The same sign-in can be an Admin in one workspace and a Viewer in another.
How a permission is decided
Three layers, each narrower than the last, applied in order:
- The platform default for the role — what an Admin, Member, Viewer or Guest gets everywhere.
- This workspace's changes to that role — an admin can grant or revoke a key for the whole role in this workspace only.
- This one person's overrides — a grant or a revocation for a single member.
A later layer always wins, and a layer can take a key away as well as add one. That is what lets an admin lock exactly one person out of billing.manage without inventing a role, and lets one workspace tighten Member without affecting any other.
Two wildcards exist: * for everything, which is what Admin holds, and project.* for a whole resource.
What a Viewer gets, and what they do not
Viewer is derived rather than listed: any key ending in .view reaches Viewer automatically, so a read permission added to the product tomorrow arrives without anyone editing a list. A .create key never does.
Some .view keys are deliberately excluded from that blanket grant, because they are commercially or personally sensitive and a guest auditor with Viewer should not walk into them:
meeting.notes.view— meeting transcripts.finance.rates.view,finance.expense.view,finance.invoice.view,finance.retainer.view— rates, spend, invoices and retainer balances.estimate.view,quote.view— unsigned deals and the prices offered on them.portal.view— the roster of external people holding a portal login.risk.view— the risk register, which names commercial exposure in money and days.
A second, smaller set is off both Viewer and Member by default, and is meant to be granted per workspace: client.view, contract.view and report.view. Turning one on is a single toggle in the admin console and the matching rows appear in that person's rail on their next request.
The three permissions people ask about most
- **
project.viewversusproject.view_all.** The first says you may open the Projects module at all. The second says you see every project rather than only the ones you were added to. Admins hold it through the wildcard; nobody else does by default, which is what makes the project member list mean something. - **
task.updateversustask.update_own.** The first edits any task. The second edits only the tasks you created, are assigned, or review. - **
report.financialversusreport.cost.** Revenue and margin are one key; what each person costs is another, because the second is salary data by another name. Withoutreport.financialthe utilisation screens still work — the money columns are absent rather than blanked, so you can tell how much you are not being shown.
Project roles and team roles
Separate from the workspace role and stacked on top of it. A project member is an Admin, Editor, Commenter or Viewer of that project; a team member is a Maintainer or a Member of that team. An invitation can carry both a workspace role and a project role at once, and the join screen shows them as two badges because they are two different grants.
Where this is changed
In the admin console, and only by someone who holds role.manage:
- Admin → Roles lists the four roles, what each currently grants, and how far this workspace has moved from the platform default.
- Admin → Permissions is the grid. The By role tab is a role × permission matrix, where a cell customised by this workspace carries a dot to distinguish it from one that is merely following the platform default. The By member tab is where a single person's overrides are set, shown as a deviation from their inherited baseline rather than as a bare tick.
Reading either screen needs role.view; changing anything needs role.manage.
A permission change reaches open sessions live — the app is told to re-ask rather than being handed the new set — so a revocation takes effect without the person signing out and back in.
Permissions are not entitlements
A permission asks are you allowed. An entitlement asks does this workspace have the feature at all, and it comes from the plan rather than from your role. A screen you cannot reach is one or the other, and the refusal says which — see Plans and entitlements.
An Admin on the Free plan cannot open scenario planning, and no permission grant will change that. A Member on the Business plan may still be refused the same screen, and an override will.
Why your rail is short
A navigation row whose destination you could not open is hidden rather than shown and refused. A row that only ever says no reads as a broken product rather than as a boundary, so the rail is filtered to what you hold. If a colleague describes a screen you cannot find, the answer is almost always a permission key rather than a bug — and your admin can tell you which one.
Related
- Core concepts — what a permission and an entitlement are.
- How permissions work — the model in full.
- Roles — the console screen.
- Permissions — the grid and the per-member overrides.
- Plans and entitlements — the other reason a screen is closed.
