Skip to main content

Roles and what each one can do

Four built-in roles, Translator, Reviewer, Developer and Admin, decide what each person can do in a workspace, and the Owners of the account that holds it can do everything.

Four built-in roles, Translator, Reviewer, Developer and Admin, decide what each person can do in a workspace, and the Owners of the account that holds it can do everything.

Who this is for

Everyone. Admins and the Owners of the account see the same table in the app, under What each role can do on People and on Roles. It reads what the code enforces rather than summarising it.

What happens next

Reviewer and Developer each add something different to what a translator can do, and an admin holds both. Each label below is the row as the table prints it.

Translator can: View the workspace; View projects, keys and translations; Edit translations; Edit translations in scoped locales.

Reviewer adds signing off: Approve (sign off) translations; Approve translations in scoped locales; View assignment work orders; Review (approve or request changes on) assignments. A reviewer cannot add keys or languages and cannot run AI translation.

Developer adds: Add and remove languages; Add and edit keys; Run AI translation, QA and self-heal; Manage in-context screenshots; Manage glossary terms. A developer cannot approve a translation.

Admin holds everything a reviewer and a developer can, and adds: Create projects; Edit project settings; Delete a project; Grant per-project access; Assign translators; Create and revoke API tokens; Manage publishable keys; Manage webhooks; Manage the CMS connection; Manage CDN delivery keys; Invite, re-role and remove members; Read the audit log (on the Enterprise plan); Manage integrations; Rename the workspace.

Account owner is not a role anybody is given. The Owners of the account that holds a workspace control it: they hold every row of the table, and four rows are theirs alone, each marked "Account owners only. No workspace role can hold it.": Delete the workspace; Configure single sign-on and SCIM; Require two-factor for everyone in the workspace; Manage white-label branding. On People they are listed apart, under Account Owners, and they are added or removed on the account's Owners & billing members page.

Every member who reaches the whole workspace also holds "See this workspace's AI words". A member limited to some projects does not.

Billing is not part of any workspace role. The plan, the card and the invoices belong to the account, and the account's Owners and Billing members manage them. A Billing member reaches no workspace through the account and holds no row of this table. Every role takes one seat on the account's plan, and nobody is charged for being a member.

A custom role sits beside the built-in role of the rank it was given and holds exactly the rows ticked for it. It can never hold the four rows that belong to the account's Owners, whatever its rank.

Editing and approving are separate. A translator or a developer may edit a value but not approve it, and a reviewer approves it, so the person who writes a translation is not the person who signs it off.

Per-project grants change a member's role for one project, and can narrow them to specific locales. Admins and the account's Owners are never narrowed this way.

Related

  • Change a teammate's role

  • Grant access to one project

  • Invite a teammate

  • The member list

Did this answer your question?