Role Based Access Control

​

Key Benefits

• Scope-level control — assign different roles to the same user across different workspaces and projects
• Least privilege by default — members get minimal permissions; admins explicitly grant access
• Custom role definitions — define custom roles with granular permissions (Enterprise plan)
• Independent scopes — permissions at one level do not automatically cascade to child levels

​

How Access Is Evaluated

1. Membership — the user must be explicitly added to the scope (via invite or auto-assignment).
2. Role with permissions — the user must hold a role that grants the required permissions in that scope.

• A user who has been invited to a project but holds no role in it will have no permissions.
• A user who holds a role at a scope level but has not been added to a specific instance of that scope cannot access it.

​

Default Roles

​

Organization Roles

​

Workspace Roles

​

Project Roles

​

Data Plane Roles

​

Permission Reference

​

Custom Roles

• The scope level it applies to (organization, workspace, or project)
• The permission set — a list of individual permissions the role grants
• Auto-assignment triggers — optional rules for when the role should be automatically assigned (e.g., on workspace creation, on invite)

​

Role Assignment

​

How roles are assigned

​

How permissions work across scopes

Organization (Org Admin)
├── Workspace A (no access -- must be explicitly added)
│   ├── Project 1 (no access)
│   └── Project 2 (no access)
└── Workspace B (Workspace Member -- explicitly added)
    ├── Project 3 (Project Admin -- explicitly added)
    └── Project 4 (no access)

• A user can be a Workspace Admin in one workspace and a Workspace Member in another.
• A user can be a Project Admin in one project and have no access to a different project in the same workspace.
• An Org Admin must be added to individual workspaces and projects to access their data.

​

Common Scenarios

​

Adding a new team member

1. Org Admin invites the user to the organization.
2. User becomes an Org Member.
3. Workspace Admin adds the user to the relevant workspace(s).
4. Project Admin (or Workspace Admin) adds the user to the relevant project(s).

​

Creating a new workspace and project

1. Any Org Member creates a new workspace — they become Workspace Admin automatically.
2. Workspace Admin creates a project — they become Project Admin automatically.
3. Workspace Admin invites team members to the workspace and assigns them to projects.

​

Restricting access within a workspace

1. Add all team members to the workspace as Workspace Members.
2. Add each member only to the specific projects they need.
3. Members will only see and access projects they have been explicitly added to.

​

Offboarding a team member

1. Remove the user from their projects (Project Admin or Workspace Admin).
2. Remove the user from their workspaces (Workspace Admin or Org Admin).
3. Remove the user from the organization (Org Admin) if they are leaving entirely.

​

Permission Recipes

​

API Key Permissions

​

Security Guarantees

• No privilege escalation — users cannot grant themselves roles or expand their own access. Role assignment requires explicit admin permissions (*.membership.set_roles) at the relevant scope.
• No permission inheritance — permissions are flat and scoped to each level independently. An Org Admin does not automatically have access to workspaces or projects. A Workspace Admin does not automatically have admin access to projects within that workspace.
• Cross-scope isolation — data queries are always filtered by scope. Traces, datasets, and search results from one workspace or project are never visible to users in another, even within the same organization.
• Separation of duties — in Dedicated Cloud and Self-Hosted deployments, platform operators (control plane) cannot access service-domain data (data plane), and service-domain users cannot modify platform or federation configuration. No role combines control plane authority with data plane access.

​

FAQ