Roles & permissions

Every person on a project has a role that decides what they can do. Roles form a ladder: each rung includes the abilities of the ones below it.

The project roles

Role	Can…
Viewer	Read cells and comments. No editing.
Commenter	Everything a viewer can, plus comment on cells.
Reviewer	Validate cells (confirm they’re correct). No content edits.
Contributor	Edit cell content, the core translating role. Also records audio, runs diarization, adopts a speaker as a voice, writes back-translations, and waives check flags.
Project lead	Invite members, assign work, create and import files, and manage terminology.
Maintainer	Manage roles (change or remove members) and edit project settings: validation rules, AI provider, and the like.
Owner	Full control, including archiving and deleting the project.

Higher rungs include the lower ones: an owner can do everything a maintainer can, and so on. By default, anyone who can read a project can export what they see; an organization owner can restrict exporting to a higher role if a project needs it.

Operator access

Separate from these seven roles, the Aquilla team holds platform-operator access, used for things like running migrations and support. It’s controlled by an internal operator allowlist, sits outside the project role ladder, and isn’t something you assign within a project.

Scopes: limiting access to specific languages or files

By default a role applies across the whole project: a contributor can edit any target language, a reviewer can validate any target language. Project leads and above can narrow that for an individual reviewer or contributor with a scope: a restriction that limits them to specific target languages (what Aquilla calls lanes, one track per target language) and/or specific files.

To scope someone, a project lead opens that member’s scope editor from the project’s people view and adds a lane code (e.g. es for Spanish) or a file. A member with no scopes shows “Unscoped — full access”, the same as before scopes existed. A scoped member can only edit and validate cells in their listed languages and files; the server rejects anything outside that.

Project leads, maintainers, and owners are always unscoped (leads see every language on the project), and only they can set or change another member’s scopes.

Scoping is different from assigning someone work. An assignment (“staffed on Spanish”) is a to-do: it points someone at work without limiting what else they can touch. A scope is a boundary: it’s what they’re allowed to touch. Project leads can staff someone onto a specific target language as reviewer or contributor in one step from the people views, which sets both at once: it adds them to the project in that role and scopes them to that language.

From the project overview’s Team card, a lead can also assign a book (or one or more of its chapters, checked from a list) to a project member in a single step, instead of creating one assignment per chapter.

Project Manager: an attribution, not a role

Separate from the role ladder above, a project can also have a Project Manager: one member marked as accountable for it, shown on the project’s Overview page and searchable and sortable in your organization’s project table. Being the Project Manager doesn’t grant any permissions by itself: what that person can actually do still depends on their role.

A project’s Overview page shows a Project manager card with Assign, Change, or Clear. The assign dialog explains the attribution: “The project manager is responsible for this project. They must be a member of the project.” Only a Maintainer or above can assign, change, or clear a project’s Project Manager, and only someone already a member of the project can be picked.

When someone has more than one grant

You might receive a role two ways at once: directly on a project, and also through a team grant. Aquilla resolves this with a simple rule:

The highest privilege wins.

So if you’re a contributor directly and a contributor via a team, you’re a contributor; if one path grants more than the other, you get the more powerful one. Aquilla manages this for you and shows you a single resolved role.

Seeing everyone’s access at once

The org Members page has a Matrix tab: “Every member × every project you can see, at a glance. Click a cell to change a role; hover a row to load its lane scopes.” Each row also names how the member’s access is resolved, and an Access model legend explains the grant paths (direct, via a team, org-wide, creator) that feed the highest-wins rule above.

When you hit a permission wall

If you try something your role doesn’t allow, Aquilla tells you exactly why instead of a bare “no”: the alert names who you’re signed in as and which role the action needs. For example: “Viewers cannot perform this action — you need at least Contributor access.” If you’re signed into more than one account, it offers a one-click account switch to try the action as the other account; either way, it links back to this page (“Learn about permission levels”) so you can check the full role ladder.