Members & roles
Invite people to the workspace and control what each of them can do. Access is a set of permissions, enforced by the backend · a role is just a named bundle of those permissions that you assign to a member.
#How permission works
A permission is a single resource:action capability · for example runs:write (drive a run) or members:read (see the roster). Actions are read, write (create or update), and destroy, and some write capabilities have finer sub-actions (for example runs:write:approve or runs:write:stop).
A role is a set of those permissions. You assign roles to members; the backend checks the member’s combined permissions on every action. There is no role hierarchy · a role can do exactly the permissions it holds, no more.
Every state-changing action checks the caller’s permissions server-side. The console only shows a control if you hold the permission behind it, so the UI and what you can actually do always agree.
#Built-in roles
Two roles ship with every workspace and are locked (you cannot edit or delete them):
To grant anything between those two, duplicate a built-in role into an editable custom role.
#Custom roles
Build a role for exactly the access a group needs:
Duplicate or start fresh
On Settings → Roles & permissions, duplicate a built-in role (a good starting baseline) or create a new one.
Set its permissions
Toggle the permissions per resource across the read / create·update / delete matrix. The role’s summary shows how many of each resource’s permissions it holds.
Assign it to members
On the Members tab, give the role to the people who need it. A member’s access is the sum of the roles they hold.
#Invite and manage members
Members live on Settings → Members, with a roster and a pending-invitations tab.
- Invite · send an email invite, or mint an open link (a bearer token · whoever holds it joins with the role you set). Requires
members:write. - Change a member’s role · requires
members:writeandpermissions:write, because changing a role changes what that person can do. - Deactivate, reactivate, remove · lifecycle actions, each behind a confirmation dialog. Removing requires
members:destroy, and the last admin cannot be removed.
Every one of these goes through a confirmation dialog rather than acting immediately.
#Who can do what
The permissions worth knowing when you set up a workspace:
Out of the box only Admin holds write permissions and Viewer is read-only, so give people a custom role when they need to do more than read but less than everything.
Built-in roles are fixed so every workspace starts from the same known baseline. To change what a role can do, duplicate it into a custom role · the built-ins themselves never change.