Every person in a workspace has one of four roles, and that role decides what they can do across every project in it. This page lists exactly what each role can and cannot do, and how per-project roles change the picture.
The four roles
| Role | Intended for |
|---|---|
| Owner | The person who created the workspace. Full control, including deleting it. |
| Admin | Trusted operators. Everything except deleting the workspace and managing billing. |
| Editor | People who work on translations. Can edit content and settings, cannot add or remove projects. |
| Member | Read-only. Can see everything, change nothing. |
Owner is not an assignable role. It belongs to whoever created the workspace. You can invite people as Admin, Editor, or Member, but ownership cannot currently be reassigned. If the owner needs to change, contact support at [email protected].
What each role can do
| Owner | Admin | Editor | Member | |
|---|---|---|---|---|
| Workspace | ||||
| View the workspace | yes | yes | yes | yes |
| Edit workspace settings | yes | yes | no | no |
| Delete the workspace | yes | no | no | no |
| Members | ||||
| View members | yes | yes | yes | yes |
| Invite and remove members | yes | yes | no | no |
| Change a member's role | yes | yes | no | no |
| View and revoke invitations | yes | yes | no | no |
| Projects | ||||
| View projects | yes | yes | yes | yes |
| Edit project settings | yes | yes | yes | no |
| Create a project | yes | yes | no | no |
| Delete a project | yes | yes | no | no |
| Languages | ||||
| View languages | yes | yes | yes | yes |
| Add a language | yes | yes | yes | no |
| Remove a language | yes | yes | no | no |
| Translations | ||||
| View translations | yes | yes | yes | yes |
| Edit translations | yes | yes | yes | no |
| Mark as verified | yes | yes | no | no |
| Delete a translation | yes | yes | no | no |
| Glossary | ||||
| View glossary rules | yes | yes | yes | yes |
| Create and edit rules | yes | yes | yes | no |
| Delete rules | yes | yes | no | no |
| Domains | ||||
| View custom domains | yes | yes | yes | yes |
| Manage custom domains | yes | yes | yes | no |
| API keys | ||||
| View, create, regenerate, delete | yes | yes | no | no |
| Billing | ||||
| View billing | yes | yes | no | no |
| Manage the subscription | yes | no | no | no |
| Analytics | ||||
| View statistics | yes | yes | yes | yes |
Two boundaries are worth calling out because they surprise people:
Only the owner can manage the subscription. An Admin can see billing but cannot change the plan, update the card, or cancel. If your billing contact is not the workspace owner, the owner has to make the change.
Three permissions have no feature behind them. Importing translations, exporting translations and exporting statistics are all defined internally, and none of them exists in the product, so no role can do them and they are left out of the table above. See Import and export translations.
Editors cannot add or delete projects. They can do almost everything inside a project, including editing its settings and managing its domains, but the project list itself is Admin territory.
Per-project roles
A workspace role applies everywhere. On top of that, a project can carry its own role for a person.
It is set from the project rather than the workspace: open the project, choose Project Members, and either invite someone there with a Project Role, or use Add Project Role on the row of someone already in the workspace. Once set, that row also offers Change Role and Remove Override.
Per-project roles only ever grant more access, never less.
| Workspace role | Per-project role | Result on that project |
|---|---|---|
| Member | Admin | Admin |
| Member | Editor | Editor |
| Member | Viewer | Member, unchanged |
| Editor | Admin | Admin |
| Editor | Viewer | Editor, unchanged |
| Admin | anything | Admin, unchanged |
| Owner | anything | Owner, unchanged |
This is the part that catches people out. Setting someone to Viewer on a project does not restrict them. If they are an Admin at workspace level, they remain an Admin on that project, and a Viewer entry changes nothing.
There is no way to reduce a person's access to a single project. If someone should not have access to a project, they should not have the workspace role that grants it. Use a second workspace instead, as described in Workspaces.
Changing someone's role
You need Admin or Owner to change a role. Editors and Members cannot change anyone's role, including their own.
- Open Members for the workspace.
- Choose Change Role on their row.
- Set the new Workspace Role and choose Update Role. It applies on their next request.
Who can change whom, and to what:
| You are | You can change | You can set them to |
|---|---|---|
| Owner | Admins, Editors, Members | Admin, Editor, Member |
| Admin | Editors, Members | Editor, Member |
| Editor | nobody | |
| Member | nobody |
Two limits follow from that table:
Only the Owner can create an Admin. An Admin can promote a Member to Editor, but not to Admin. If you need another Admin, the Owner has to make them one.
Admins cannot touch each other. An Admin cannot demote, promote, or remove another Admin, and nobody can change the Owner's role.