Skip to main content

Roles

Roles bundle permissions. Instead of assigning 20 permissions per user, create a "Viewer" role once and assign it everywhere.

How it works​

Roles inherit from parent roles. Editor extends Viewer — it gets all of Viewer's permissions plus its own. Change Viewer's permissions and every role that inherits from it updates instantly.

Common patterns​

Viewer (read-only)​

{ "id": "viewer", "name": "Viewer", "permissionIds": ["documents:read", "reports:read"] }

Editor (read + write)​

{ "id": "editor", "name": "Editor", "permissionIds": ["documents:read", "documents:write"] }

Admin (full access)​

{ "id": "admin", "name": "Admin", "permissionIds": ["*:*"] }

Template roles​

Mark a role as a template to make it clonable. Template roles can't be assigned directly — they're blueprints. Clone a template into a scope to create an independent copy.

Edge cases​

  • Circular inheritance is blocked. Assigning editor as the parent of viewer when viewer is parent of editor throws CircularRoleHierarchy.
  • Deleting a role does not cascade to policies. Policies referencing a deleted role will have one fewer role to evaluate.
  • Deleting a permission referenced by a role automatically cleans up the dangling reference. No manual cleanup needed.

In the dashboard​

[Screenshot: Role list showing viewer, editor, admin with permission counts and parent indicators]

Navigate to Roles. Click New Role, name it, select permissions from the list, and optionally pick a parent role to inherit from.