- If you’re using built-in roles, scan the columns below to see which permissions each role gets.
- If you’re writing a custom role, pick the action names you want to allow or deny.
Conventions
Each table lists role actions for one kind of resource, with a column per built-in role:- Team Admin is granted to any team member with the built-in Admin role.
- Team Developer is granted to any team member with the built-in Developer role. Members assigned custom roles do not receive Developer-level access.
- Project Admin is granted to any team member who additionally holds the Project Admin role on the specific project that owns the resource. Project Admin sits alongside the member’s built-in or custom role; Team Admins implicitly have Project Admin on every project.
- ✓ - the role grants this action.
- ✗ - the role does not grant this action.
- ✓ non-prod - the role grants this action only on non-production deployments. Granting the action on a production deployment requires Team Admin or Project Admin on that project.
- N/A - the action does not apply to that role (e.g. Project Admin on team-scoped actions).
Team
Resource leaf:team:*.
Both
team:auditLog:view and team:usage:view reveal the existence of every
project on the team. The audit log contains entries that reference projects and
deployments across the whole team, and the usage page breaks down consumption
per project. Grant these actions only to members who should know what projects
the team has, even if they cannot otherwise access those projects.Billing
Resource leaf:billing:*.
OAuth applications
Resource leaf:oauthApplication:*.
SSO
Resource leaf:sso:*.
Authentication domains
Resource leaf:team:*. These cover the Authentication Domains section of
the team authentication page, which both SSO and
Directory Sync read.
Directory Sync
Resource leaf:directorySync:*.
Reviewing the staged roster before enabling Directory Sync also requires
member:view, because it lists each team member and their role.
Team integrations
Resource leaf:integration:*.
Members
Resource leaf:member:*.
Custom roles
Resource leaf:customRole:*.
customRole:create, customRole:update, and customRole:delete are reserved
for Team Admins and cannot be granted through a custom role.
Projects
Resource leaf:project:* (or project:slug=…, project:id=…). Project Admin
applies on the specific project the action targets.
Default project environment variables
Resource leaf:project:…:defaultEnvironmentVariable:*.
Deployments
Resource leaf:project:…:deployment:* (optionally filtered with selectors like
:type=prod).
Most deployment-modifying actions are gated by whether the deployment is
production. Team Developers can perform them on dev, preview, and custom
deployments via team membership, but production deployments additionally require
Team Admin or Project Admin on the owning project. The same split applies to
data-plane actions: on a production deployment, a Team Developer gets a
read-only deployment identity unless they’re also Project Admin on that project.
Lifecycle and configuration
Data plane and runtime
These actions run against the deployment itself. On production deployments, a Team Developer who isn’t also Project Admin gets a read-only deployment identity.Backups
Access tokens
Access tokens nest under their owning resource. The actions follow the same prefix as the owner;team:token:* for team-scoped tokens, project:token:*
for project-scoped, and deployment:token:* for deployment-scoped.
Team-scoped tokens (resource leaf: team:*:token:*)
All of these actions are scoped to tokens you personally created.
A team access token can only perform actions its creator is allowed to perform.
If the creator has custom roles, the token is
limited to the actions those roles allow, so issuing a token never escalates the
creator’s privileges.
Project-scoped tokens (resource leaf: project:…:token:*)
Deployment-scoped tokens (resource leaf: project:…:deployment:…:token:*)
Deploy keys and preview deploy keys are service tokens. Once issued, they carry
their own permissions independent of the creator’s current role: if a team
member has already created a deploy key or preview deploy key, that key
continues to work with its original permissions even if the member’s team role
or custom role later changes. To revoke a key’s access, delete the key from the
deployment or project settings page.