Skip to main content
Available on the following plans: Dev Pro Enterprise Role-based access control (RBAC) lets you decide exactly what each member of your organization can see and do, per workspace. It is built from two pieces that you manage from the Members section in admin:
  • Roles bundle the scopes (permissions) a member can use. A role says what someone may do, but nothing about where.
  • Groups grant one or more roles across one or more workspaces, and members join groups. A group says who gets which roles and where.
A member’s effective permissions are the union of every role granted by every group they belong to, evaluated per workspace.
A member who belongs to no group keeps full access, which is what keeps existing members working while you roll RBAC out. Access only narrows once you add someone to their first group, so you can introduce access control one member at a time.

​
The Members section

The Members page has three tabs:
Members directory listing each member with their email and groups

Members directory with the Groups column

​
Roles

A role is a named set of scopes. Scopes are organised by service, and each resource within a service can be granted at one of two levels: Ticking the Read or Admin checkbox in a service’s header grants that level for every resource in the service, including resources added to that service in the future. The individual rows are then locked, since the service-wide scope already covers them.

​
Available scopes

Anyone with Admin on Roles, Members or Everything can change who has access to what, including granting themselves more access. Keep these scopes to a small number of trusted administrators.

​
Create a role

  1. Navigate to Members in admin and open the Roles tab.
  2. Click New role in the top right corner.
  3. Enter a Name and, optionally, a Description.
  4. Tick the Read or Admin checkbox for each resource the role should grant, or use the header checkbox to grant a whole service.
  5. Click Create role.
New role form showing the Read and Admin checkboxes for each service and resource

New role form with the scope matrix

Roles are reusable: define them once and grant them through as many groups and workspaces as you need. A few common patterns:

​
Groups

A group connects roles to workspaces and members to the group. When you create a group you pick which roles it grants and where each of them applies. A single group can cover several roles across several workspaces, so you can usually model a team with one group. The Access table in the group form has one row per workspace plus an Entire organization row, each with a dropdown to select one or more roles. Granting a role on the Entire organization row applies it across every workspace and also covers organization-level settings that belong to no single workspace, such as billing, members and domains. Access scopes only take effect when granted on the Entire organization row.

​
Create a group

  1. Navigate to Members in admin and open the Groups tab.
  2. Click New group in the top right corner.
  3. Enter a Name that reflects the team or function the group represents, and optionally a Description.
  4. In the Access section, select the roles the group grants on each workspace row, or on the Entire organization row for organization-wide access.
  5. Click Create group.
New group form showing the roles granted on the organization and each workspace

New group form with roles granted per workspace

You need at least one role before the group form lets you grant anything. If the Access section reads No roles yet, use the Create role shortcut to define one first.

​
Assign groups to a member

Groups are assigned from the member’s own page:
  1. Navigate to Members in admin and open the Directory tab.
  2. Click the member’s row.
  3. In the Groups section, select the groups the member belongs to. Remove a group by clicking the cross on its chip.
  4. Save the member.
Member page showing the name, position and the Groups selector with one group assigned

Member page with the Groups selector

To review a single member’s access, find them in the Directory tab: the Groups column lists every group they belong to.

​
Example: a finance team with read-only auditors

Suppose you run two workspaces, Spain and Portugal, and want:
  • The finance team to manage documents in both workspaces.
  • An external auditor to read documents in Spain only.
  • Two administrators with full control.
  1. Create three roles: Operator (Admin on Silo Entries, Read on Transform), Viewer (Read on Silo and Transform) and Owner (Admin on Everything).
  2. Create a Finance group granting Operator on the Spain and Portugal rows, and add the finance team.
  3. Create an Auditors group granting Viewer on the Spain row only, and add the auditor.
  4. Create an Admins group granting Owner on the Entire organization row, and add the two administrators.

​
FAQ

They keep full access to every workspace, exactly as before RBAC. Access is only restricted once a member belongs to at least one group, so review the Directory for members whose Groups column reads None once your rollout is complete.
Yes. Their permissions are the union of every role granted by every group, per workspace. There are no deny rules, so adding a second group can only widen access. Adding the first group narrows it, since it replaces the default full access.
No. A role is a fixed set of scopes. Create separate roles if two workspaces need different permission sets, then grant each role on the relevant workspace rows of a group.
Billing, members, domains and other Access scopes belong to the organization, not to any single workspace. Grant the role on the Entire organization row of the group instead.
Remove them from their groups to narrow their access, or deactivate them to remove it entirely. See Disable members.