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, waives check flags, and, by default, resolves or reopens any comment thread, including ones a teammate started (an org owner can move this floor; see Org settings & billing).
Project lead	Invite members, assign work, create and import files, and manage terminology. On a dubbing project, also links a video to a file, pairs subtitle lines to audio cues, and runs the character/pairing checks.
Maintainer	Manage roles (change or remove members) and edit project settings: validation rules, AI provider, and the like. On a dubbing project, also casts characters, imports or clears character sheets, removes an imported source, and unlocks the timeline against dragging.
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.

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, open the org Members page, go to its Matrix tab, and click the small scope text under that member’s role on the project. A popover titled “{username}’s scopes” opens with a Languages they can work in checklist of the project’s own target languages, starting with the main language (named by the project’s target language, or Main language when none is set). Tick the languages and click Save scopes. A member with nothing ticked 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. A scope naming a language the project no longer has appears as “{lane} (not a language in this project)” so you can untick it.

A member limited to some languages opens the editor on one of their own languages and can switch among those, instead of landing on the main language. Below Maintainer (a Project lead included), a member also sees only the languages they were given: other languages’ names and progress counts are hidden from them, and their Health Ring counts only their own languages.

Maintainers and owners are always unscoped and see every language on the project. A Project lead can be limited to some languages like a reviewer or contributor, and sees only those. Project leads and above 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. See Lane access & staffing.

Where a lane has its own name, that name shows in lane pickers, chips, and assignment lists in place of the language code. See Languages & target lanes.

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.

Lane coordinators: assigning within one language

An organization owner can let people limited to specific languages assign work in those languages. With Allow lane coordinators to assign work on (see Org settings & billing), a Contributor or above who is scoped to one or more languages, such as a mentor, can assign work in those languages only, with no other admin rights. The setting does nothing for a member with no language limit. It works for a guest too: an outside mentor who is a project member but not in the organization. See Teams & assignments for what a coordinator sees and can do.

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. Naming someone Project Manager also adds them as a Project lead on that project, and an existing higher role is kept. Clearing the Project Manager does not remove that Project lead membership; the Overview page says so while a manager is set (“Naming them project manager also adds them as a Project lead on this project. An existing higher role is kept. Clearing the project manager does not remove that membership.”). What the person can do comes from that role, not from the attribution.

A project’s Overview page shows the Project manager next to its deadline, near the top of the page. A pencil icon next to either one opens a dialog to change it; the project manager dialog explains the attribution: “The project manager is responsible for this project. They must be a member of the project.” A Clear button inside that dialog removes the current value. 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.

Where a member’s access comes from

Each person on a project’s Members list, an organization’s Members page, or a team’s Members tab carries a small badge that says how their access arrived:

Direct: a role given to that person at this level.
Creator: they created the project.
Inherited: the role comes from a higher level, such as a team or the organization. When Aquilla knows where, the badge names it, for example Inherited · {path}.

On a project’s list, a role that is only inherited shows in place but disabled. Hover it to read “Set at {path} — change it there”, where {path} is the place that holds the grant, with the levels joined by ›. A Change at {path} link beside it takes you there.

Click a person’s name to open a small panel about them. It is read-only and has two parts: Effective here ({path}), their role in the place you opened it from and each grant that adds up to it, and Everything else, their other access you can see, or “No other access you can see”. Each grant names its origin and, when known, who gave it and when (“by {name}”). On your own row the panel is titled Your access. A person who is not a member of the organization is marked Guest of {org}. On the organization’s Members page the panel also has a Manage access button, which expands that person’s row. If you aren’t allowed to see someone’s access, the panel says “You can’t see this person’s access.”

Changing a member’s role on a project

On a project’s Members list (Project Settings), only a Project lead or above can change roles or add members. Below that level the controls stay in place but disabled, with the reason: “Project lead or higher can change member roles”. You also cannot change a member whose role is at or above your own (“You can’t change a member whose role is at or above your own”), or your own role. Members whose access comes from the organization roster, or who created the project, have no direct grant to change on the project; use Revoke all access… where it applies.

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.

To add someone from the matrix, click an empty cell and pick a role. Below Maintainer, on a project with target lanes, the popover then asks which Target lanes the person gets and waits for your choice before it adds them. See Lane access & staffing.

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. When the server refuses an action, the message also says where your role comes from, in the form “You are {role} here ({origin}). {required} is required.” The origin is the kind of grant (Direct, Via group, Org-wide, Creator) followed by its place when known. If you have no role at all, it reads “You don’t have a role here. {required} is required.” 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.

When edits were not saved, a banner says why and names the language: “1 change wasn’t saved — you weren’t allowed to work in {language} at the time” (or “in the main language”). A refusal on role alone reads “your role wasn’t allowed to edit translations on this project”.