Skip to main content
TextSetu controls access with role-based access control (RBAC) at three levels: organization, project, and team. A person can hold multiple roles at each level, and their effective permissions are the union of everything those roles grant.

​
How access is granted

A person’s access can come from several places at once:
  • Organization role(s) — apply across the whole organization.
  • Project role(s) — apply to a single project (granted directly or via a team).
  • Team role(s) — their standing within a team, plus whatever that team is assigned to.
Because roles stack, someone can be, for example, both a Project Editor and a Project Approver — able to edit and approve.

​
Organization roles

​
Project roles

Editor + Approver: Translators who are not approvers have their edits saved as proposals when approval is required. Approvers’ edits publish directly. Give a trusted translator both roles to let them self-approve.

​
Team roles

​
Who can approve translations

When a project has Approval required turned on, the approval workflow applies. The ability to approve or reject is granted to:
  • Organization Owner
  • Organization Admin
  • Project Admin
  • Project Approver
Anyone else who can edit will have their changes saved as pending review.

​
Managing roles

On any Access page (organization, project, or team):
  • Add member — invite by email and pick one or more roles.
  • Change roles — update a member’s roles at any time (multi-select).
  • Remove — revoke a member’s access at that level.
Role changes take effect immediately for active members.

​
Tips

  • Prefer teams for groups who share the same project set — it’s less to maintain than per-person grants.
  • Use Viewer roles for stakeholders who need visibility but shouldn’t edit.
  • Combine Editor + Approver sparingly, and only for trusted reviewers, to keep the approval gate meaningful.

​
Permissions and API tokens

The same permission catalog that powers roles also governs the API. When you create an API token (Settings → API tokens, or a project’s API tokens), you pick an allow-list of individual permissions — the token grants exactly those and nothing more. To make it quick, the picker offers role presets (Viewer / Editor / Admin) that tick the matching permissions, which you can then fine-tune. Two guarantees keep tokens safe:
  • A token can only narrow, never escalate. A Personal Access Token acts as you, but limited to the permissions you granted it and bounded by the roles you actually hold — it can never do more than you can. A project token is additionally locked to its one project.
  • You can’t grant what you don’t have. Selecting a permission you don’t hold on the target project is rejected when the token is created.
In the admin console, the Permissions page shows an API · N badge on each permission that gates one or more API endpoints, so you can see at a glance which permissions are meaningful to grant to a token.
Related: Organizations & Teams · Approval Workflow