---
title: "Roles"
slug: admin/roles
url: https://projectri.com/docs/admin/roles
section: admin
audience: admin
app_route: "/[slug]/admin/roles"
permissions: [role.manage]
mobile: false
updated: 2026-09-08
source: Projectri documentation
---

# Roles

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.

![Roles](https://projectri.com/docs-shots/admin-roles.png)

## What it is

Roles lists the four company roles — **Admin**, **Member**, **Viewer**,
**Guest** — with a headcount, a description, how many of the permission
catalogue each currently grants, and how many of those grants this workspace has
customised. It is the summary screen; the editing happens on
[Permissions](/docs/admin/permissions).

## How to get there

**Admin → People → Roles**. Reaching the console needs the ADMIN role. Reading
and resetting the matrix behind this screen is keyed on `role.manage`.

## How to use it

### Read a role card

1. Each card shows the role, a member count, and a sentence describing it:
   - **Admin** — runs the workspace: every module, plus billing, security and
     this console.
   - **Member** — does the work: creates and edits projects, tasks, documents
     and calendar entries.
   - **Viewer** — reads everything they are given access to and changes nothing.
   - **Guest** — an outside collaborator; sees only what has been shared with
     them explicitly.
2. The bar underneath is grant coverage — *"84 of 312 permissions"*.
3. An amber **N customised** pill means this workspace has changed N cells away
   from the platform default for that role. No pill means the role is exactly as
   shipped.

### Change what a role grants

1. Press **Edit permissions** on the card, which opens
   [Permissions](/docs/admin/permissions) on the **By role** tab.
2. Toggle the cells you want. Each change is saved as it is made.

### Put a role back to the platform default

1. **Reset to default** appears on a card only once it has been customised.
2. The confirmation says what it will do: undo every permission change this
   workspace has made to that role.
3. The toast reports the count — *"MEMBER reset — 6 changes undone"* — or tells
   you the role was already at the default.

Per-member overrides are **not** touched by a reset. Somebody who was granted a
key personally keeps it.

## What it affects

- **Everyone holding the role, at once.** A reset or an edit re-publishes the
  permission set to the whole workspace, and every open tab re-reads its own
  keys rather than waiting for a reload.
- **The nav rail.** Most rows in the sidebar are drawn from a `.view` key, so
  granting or revoking one adds or removes a destination from every holder's
  navigation on their next request.
- **Nothing outside this workspace.** A customisation is stored as a delta row
  against this company. The underlying platform default table is shared by every
  tenant and is never edited from here.
- **The audit log.** Every grant, revoke and reset is written to the trail with
  the key, the role and who did it.

## On mobile

This screen is web only.

## Limits and gotchas

- **There is no fifth role, and no "create role" button.** A member's role is a
  fixed database enum of four values; a new one cannot exist without a schema
  migration. What people usually want — "this person is a Member but may also
  see billing" — is a per-member override on
  [Permissions](/docs/admin/permissions), which does not require inventing a
  role at all.
- Admin holds a real wildcard rather than an enumerated list, so a permission
  key added to the product tomorrow reaches admins with no action from you. The
  other three roles are enumerated deliberately, so a new key does not silently
  widen what a Member can do.
- The member counts come from the roster, so a suspended person is still counted
  under the role they hold.
- Resetting a role is not undoable from this screen. There is no "restore my
  customisations" — the deltas are deleted.

## Related

- [Permissions](/docs/admin/permissions) — the grid where the actual editing happens.
- [Members](/docs/admin/members) — assigning a role to a person.
- [Roles and permissions](/docs/start/roles-and-permissions) — the concepts, in plain language.
- [The permission model](/docs/features/permissions-model) — how a grant is resolved at request time.

## Related

- [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.
- [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.
- [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.
- [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.