Roles and permissions
The five seats, what each one reaches, and the three ways access can be narrowed further
Every member of your organization holds one role. The role decides which pages exist for them, and the server enforces it, so a page missing from your sidebar is also a page that will not open if you type its address.
The five seats
| Role | What it is for |
|---|---|
| Owner | Full control. Team, branding, keys, webhooks, flows, review decisions, everything |
| Review manager | Runs the console. Everything an owner can do except adding people to the team or changing what their seats reach |
| Developer | Integrates. API keys, webhooks, flows, logs, usage export, and applicant details for debugging. No team, no security settings, no review decisions |
| Reviewer | Works the review queue. Decides cases, sees applicant details and edits them. No keys, webhooks, flows, usage or team |
| Viewer | Read-only across the console, and never applicant identity |
A role is a starting point, not a cage. On a colleague's member page an owner can tick individual permissions on and off, and the role is simply the preset those ticks start from. Changing somebody's role clears every individual permission they had, because the new role brings its own set.
Two rules bound all of it. Nobody can grant a permission they do not hold themselves, and a handful of the most consequential ones can be handed out by an owner only: seeing applicant identity, editing it, exporting it, deciding cases, integration logs, minting API keys, shaping the team, the outbound sender, the account's country rules, and team activity. A review manager can staff the seats below them without inheriting the ability to give away production credentials.
Why some permissions come bundled
Some capabilities imply another and are granted together, because holding one without the other produces a seat that cannot do its job.
Deciding a case carries the ability to see who the applicant is. Deciding an identity check without seeing the identity is guesswork, so the two are one seat. Exporting verifications requires being able to reveal them, for the obvious reason that a file of applicant identities must not be reachable from a seat that may not see a single one on screen.
Edit applicant data carries the ability to see applicant details, because changing a value means reading the one it replaces. Owners, review managers and reviewers hold it by default; developers and viewers do not. It is separate from Re-read a document, which asks the engine to read the images again: a developer reproducing a reading problem needs that one, and has no reason to rewrite a decided customer's identity. Editing is described on Verifications.
Escalating a case and resolving somebody else's escalation are deliberately separate. An escalation exists to move a decision away from the person who raised it, so anyone able to resolve one purely by virtue of being able to decide could resolve their own.
Retiring cases is separate from deciding them for the opposite reason, and it is the one review permission that does not carry the ability to see applicant identity. Retiring records no outcome about anybody, so it has no business demanding the right to look at their documents first. It sits with owners and review managers rather than with reviewers: clearing a backlog is a decision about how the operation runs, not case work.
Three ways a seat gets narrower
Role is the first axis. Two more sit beside it on the Team page, and both are common in real accounts.
Environments. A member holds sandbox, live, or both. This is the only thing standing between a colleague and real applicant data. See Environments.
Flows. An account is often several businesses under one roof. A seat can be restricted to specific flows, and that hides every verification, person and review case outside them. Restrict somebody to nothing at all and they see nothing at all, which the console warns you about as you do it.
What happens when a page is closed to you
You get a short page saying your permissions do not include this section, and naming who can change it: an owner, or anybody on your team who manages access, from your member page.
Inside a page you can open, controls you may not use are not hidden, they are disabled, with a line explaining that your role can view these settings but not change them. That is on purpose. Knowing a control exists is how you know what to ask for.
Viewing applicant identity is always recorded
Names, dates of birth, document numbers and photographs are encrypted, and revealing them is an action with your name on it. Every view lands in Team activity, whatever your role. Exports go further and ask for a code from your authenticator app first, because a file of identities on a laptop is something we can never recall, expire, or audit again after the first second.