--- title: "Permissions" slug: admin/permissions url: https://projectri.com/docs/admin/permissions section: admin audience: admin app_route: "/[slug]/admin/permissions" permissions: [role.manage] mobile: false updated: 2026-09-08 source: Projectri documentation --- # Permissions 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. ![Permissions](https://projectri.com/docs-shots/admin-permissions.png) ## What it is Permissions is a grid: every permission key down the side, the four roles across the top, and a tick where the role holds the key. A second tab does the same for one person, so somebody can be given a key their role does not carry — or have one taken away that it does. A key is named `.`. Anything ending `.view` is read-only; every other verb changes something and writes an audit row when it is used. ## How to get there **Admin → People → Permissions**. The console needs the ADMIN role, and reading or writing the matrix is keyed on `role.manage`. ## How to use it ### Change what a role may do 1. Stay on the **By role** tab. 2. The grid is grouped by category — Project, Task, Time, Billing, Security and so on. Click a category header to collapse it. 3. Each row shows the human description and the raw key underneath, e.g. `project.delete`. 4. Click a cell to toggle it. The change saves as you click; there is no save button. 5. A cell with an **amber dot** differs from the platform default. Hovering says which: *"Platform default"* or *"Customised for this workspace"*. 6. The count at the top right of the tabs — *"12 customised for this workspace"* — is the total across all four roles. ### Give one person more (or less) than their role 1. Switch to the **By member** tab. 2. Pick somebody from the list on the left. 3. The header says what they inherit — *"Inherits 84 from MEMBER · 2 overrides"*. 4. Toggle any key. A cell that no longer matches the role is labelled in amber beside the key: *"granted · role says no"*, or *"revoked · role says yes"*. 5. **Reset to role** clears every override for that person and returns them to exactly what their role grants. ## What it affects - **Every holder of the role, immediately.** Saving publishes the change to the workspace, and open tabs re-read their own keys rather than waiting for a reload. - **The navigation rail.** Most sidebar rows are drawn from a `.view` key, so a toggle here adds or removes a destination from somebody's navigation. - **Only this workspace.** A change is stored as a delta row against this company. The platform-wide default table is shared by every tenant and is never written from here. If you set a cell back to whatever the platform default says, the delta row is deleted rather than stored, so the matrix stops showing it as customised. - **The audit log** records every grant, revoke and reset with the key, the target and the actor. ## On mobile This screen is web only. A permission matrix is not a 390pt document. ## Limits and gotchas > [!WARNING] > Every new `.view` key reaches **Viewer** by default. Viewer's grants are > derived from the suffix — anything ending `.view` that is not on the sensitive > exclusion list is inherited automatically. That is right for `task.view` and > wrong for anything commercially sensitive, so keys like `finance.rates.view`, > `estimate.view`, `quote.view`, `booking.view`, `risk.view`, > `meeting.notes.view`, `security.view` and `privacy.request.view` are excluded > by name and must be granted deliberately. A Viewer can be a guest on a client > login, so this matters more than it sounds. - **A grant does not take effect until the RBAC seed has run.** The permission key catalogue and the default role grants live in a global table that is reconciled by a seeding step, not by this screen. A permission key that has been added to the product but not yet seeded resolves to nothing, and the toggle you flip for it is inert. Per-member overrides are never touched by that reconciliation — those are your deliberate edits. - **Admin cannot give up `role.manage`.** That cell is disabled with the tooltip *"Admins always keep this — removing it would lock everyone out of this page"*, and the server refuses it as well. There would be no way back short of a database edit. - **Admin holds a wildcard.** Its row shows every key ticked because the role grants `*`, so a key added to the product tomorrow reaches admins without any action here. - **Some `.view` keys are off the everyday floor without being secret.** `client.view`, `contract.view`, `report.view`, `proof.view`, `kb.view`, `form.view` and `playbook.view` are grants rather than inheritances — a developer hired to close tickets has no errand on the client book. Turn any of them on for a role here and the row appears in that person's nav on their next request. - A key that reads as a permission but is not in the catalogue does nothing. If a gate is written against a key that does not exist here, it refuses everybody, admins included. - The grid is optimistic: a cell flips as you click and reverts with an error toast if the write is refused. ## Related - [Roles](/docs/admin/roles) — the four roles, headcounts and reset-to-default. - [Members](/docs/admin/members) — who holds which role. - [The permission model](/docs/features/permissions-model) — how a key is resolved on a request. - [Roles and permissions](/docs/start/roles-and-permissions) — the concepts. ## Related - [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. - [Members](https://projectri.com/docs/admin/members.md): The workspace roster and the pending invite list — invite people, change roles, suspend, remove, and do any of those to many people at once. - [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 and permissions](https://projectri.com/docs/start/roles-and-permissions.md): The four workspace roles, the permission keys behind them, and why two people in the same workspace see different screens.