Roles & Permissions
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. 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.
Organization 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 — organization keys are limited to roles whose permission set is engine:access only.
Organization API keys#
Organization keys are an RBAC-only construct. Personal keys exist on every plan and inherit their creator's role; Organization keys exist only when the RBAC entitlement is active and carry their own authority.
- Creating an organization key requires
org:manage_team, the same scope that governs role assignment. - An organization key with no role is valid — its access comes entirely from the engines listed on the key.
- If the Enterprise plan ends, every organization key 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 organization keys from the API Keys page.
Ownership#
There is no separate transfer-ownership step. An Owner hands ownership to someone else by assigning them the Owner role from the Team page role picker, and the organization must always keep at least one Owner. To step down, promote another member to Owner, then lower or remove your own role.