Scopes
Scopes are isolated containers for tenants and workspaces. Permissions, roles, and policies inside one scope have no effect on another.
How it works
Create an organization scope for each customer. Create workspace scopes for teams, projects, or environments. Create application scopes for data-plane isolation.
Access granted at a parent scope flows down to children. Alice has the viewer
role in org:acme — she can read in every workspace under it. Child scopes can
opt out with allowRoleInheritance: false.
Scope types
| Type | Has parent? | Typical use |
|---|---|---|
organization | No | One per customer or tenant |
workspace | Yes — organization | Teams, projects, environments |
application | Yes — workspace | Data-plane RBAC partitioning |
Edge cases
- Deleting a scope cascade-deletes all descendant scopes and their resources (permissions, roles, policies, API keys, team members, webhooks). Scopes are deleted leaf-first — children before parents.
- Scope IDs are immutable. Choose a naming scheme before creating anything:
org:{id},org:{id}:workspace:{id}. - Cross-scope access is not possible. A policy in
workspace-engnever affectsworkspace-mkt.
In the dashboard
[Screenshot: Workspace tree showing org:acme with child workspaces eng and mkt]
Navigate to Workspaces to view the scope hierarchy. Click any scope to see its permissions, roles, and policies. Create new workspaces from the org view.