> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textsetu.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles & Permissions

> Role-based access control across organizations, projects, and teams.

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

| Role         | Typical use             | Can do                                             |
| ------------ | ----------------------- | -------------------------------------------------- |
| **Owner**    | Founder / account owner | Everything, including deleting the org             |
| **Admin**    | Localization manager    | Manage members, teams, projects, settings          |
| **Editor**   | Senior translator       | Edit translations, glossary, and TM across the org |
| **Viewer**   | Stakeholder             | Read-only access                                   |
| **Member**   | Generic member          | Baseline access; project/team roles refine it      |
| **External** | Outside collaborator    | Limited, scoped access                             |

## Project roles

| Role                 | Can do                                                   |
| -------------------- | -------------------------------------------------------- |
| **Project Admin**    | Manage the project, its members, settings, and approvals |
| **Project Editor**   | Add/edit keys and translate values                       |
| **Project Approver** | Review and approve/reject proposed translations          |
| **Project Viewer**   | Read-only access to the project                          |
| **Project External** | Limited, scoped project access                           |

> **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

| Role            | Can do                                         |
| --------------- | ---------------------------------------------- |
| **Team Admin**  | Manage the team and its members                |
| **Team Member** | Belong to the team and inherit its assignments |

***

## Who can approve translations

When a project has **Approval required** turned on, the
[approval workflow](/docs/guides/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](/docs/guides/organizations-and-teams) · [Approval Workflow](/docs/guides/approval-workflow)