--- title: "Roles and permissions" slug: start/roles-and-permissions url: https://projectri.com/docs/start/roles-and-permissions section: start audience: everyone permissions: [role.view, role.manage] mobile: false updated: 2026-09-08 source: Projectri documentation --- # Roles and permissions The four workspace roles, the permission keys behind them, and why two people in the same workspace see different screens. ![Roles and permissions](https://projectri.com/docs-shots/admin-roles.png) 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: 1. **The platform default for the role** — what an Admin, Member, Viewer or Guest gets everywhere. 2. **This workspace's changes to that role** — an admin can grant or revoke a key for the whole role in this workspace only. 3. **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. > [!NOTE] > A member who has been suspended or removed resolves to **no keys at all** — > not to Guest. Guest still carries a few read grants, and a suspended account > should carry none. ## 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.view` versus `project.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.update` versus `task.update_own`.** The first edits any task. The second edits only the tasks you created, are assigned, or review. - **`report.financial` versus `report.cost`.** Revenue and margin are one key; what each person costs is another, because the second is salary data by another name. Without `report.financial` the 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](/docs/features/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](/docs/start/concepts) — what a permission and an entitlement are. - [How permissions work](/docs/features/permissions-model) — the model in full. - [Roles](/docs/admin/roles) — the console screen. - [Permissions](/docs/admin/permissions) — the grid and the per-member overrides. - [Plans and entitlements](/docs/features/plans-and-entitlements) — the other reason a screen is closed. ## Related - [Core concepts](https://projectri.com/docs/start/concepts.md): Workspace, project, task, client, time entry — the eight words the rest of the product assumes you already know. - [How permissions work](https://projectri.com/docs/features/permissions-model.md): The three tiers Projectri decides "may this person do this" with, how a role default becomes one person's answer, and the two traps that catch every new key. - [Roles](https://projectri.com/docs/admin/roles.md): The four company roles, how many people hold each, how far this workspace has moved from the platform default, and how to put a role back. - [Permissions](https://projectri.com/docs/admin/permissions.md): The role-by-permission grid and the per-member override table — what each role may do in this workspace, and how one person differs from their role. - [Plans and entitlements](https://projectri.com/docs/features/plans-and-entitlements.md): What each plan includes, what happens when you hit a limit, and why losing a feature never loses the data behind it.