Roles

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.

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.

1. The bar underneath is grant coverage — "84 of 312 permissions".
2. 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 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, 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 — the grid where the actual editing happens.
• Members — assigning a role to a person.
• Roles and permissions — the concepts, in plain language.
• The permission model — how a grant is resolved at request time.