Role-based access control (RBAC) lets you define custom roles and assign granular permissions to your team members. Available on the Enterprise plan.
When RBAC is on, every member's permissions come from their assigned role — a member without a role can sign in but cannot manage anything. Without RBAC, all members have full access by default (see Team).
Permissions#
Five permissions make up every role:
| Permission | Scope | Grants |
|---|---|---|
org:manage_team | Organization | Invite or remove members, create or edit roles, assign roles |
org:manage_settings | Organization | Edit organization name, timezone, integrations |
org:manage_billing | Organization | View and change billing, plan, and invoices |
org:delete | Organization | Delete the entire organization |
engine:access | Engine | View, edit, delete, and manage members on localization engines |
org:manage_billing and org:delete are Owner-exclusive — only the current Owner can grant either of them by assigning a role that includes them.
Roles#
Three kinds of roles exist:
- Owner — system role with every permission. The user who creates the organization is the first Owner; an existing Owner can appoint additional Owners. The role itself cannot be edited or deleted, and the organization must always have at least one Owner.
- Full Access — seeded automatically when an organization is created with
org:manage_team,org:manage_settings, andengine:access. Editable like any custom role; a safe default for trusted teammates. - Custom roles — any role you create. Pick a name and any subset of the permission catalog.
Roles are bundles
A user holds exactly one role at the organization level. To give partial access, create a role with that exact permission subset and assign it. You cannot grant individual permissions outside of a role.
Assigning a role#
Open the Team page, pick a member, and select a role. Removing the role leaves them as an organization member with no permissions — they remain signed in but can't access any engines, settings, or billing.
Only an existing Owner can promote another member to Owner or demote one — those changes need the Owner permission set themselves.
Engine access#
By default, any member whose role includes engine:access sees every localization engine in the organization.
To narrow access, add specific users to specific engines from that engine's Members tab. Per-engine grants are additive — an organization-level engine:access always wins. To restrict a user to a single engine, give them a role without engine:access, then add them to that engine individually.
Service API keys follow the same model: a key may carry a role (umbrella permissions), a per-engine scope, both, or neither. Anti-escalation guards apply on create and on edit — service keys are limited to roles whose permission set is engine:access only.
Service API keys#
Service keys are an RBAC-only construct. Personal keys exist on every plan and inherit their creator's role; Service keys exist only when the RBAC entitlement is active and carry their own authority.
- Creating a service key requires
org:manage_team, the same scope that governs role assignment. - A service key with no role is valid — its access comes entirely from the engines listed on the key.
- If the Enterprise plan ends, every service key in the organization is deactivated with a typed 403 that names the entitlement, so the operator knows to restore the plan or rotate to a Personal key rather than chase a phantom engine-scope bug.
Manage roles and engine scope for service keys from the API Keys page.
Transferring ownership#
If you're the only Owner and want to step down, use "Transfer ownership" from the Team page. Pick the new Owner and the role you want to hold afterwards (or no role at all) — promotion and self-demotion commit in a single transaction, so the organization is never left without an Owner.
This flow is specifically for stepping down. If you just want to share Owner duties, promote a second user to Owner from the regular role picker instead.