Roles & personas reference

In one line. Every role a person can hold — platform, workspace and project — plus the personas your own solution defines. You’ll be able to. Tell a role from a persona, pick exactly the right one to hand out, gate a lifecycle stage to a persona, preview the result with View as, and take access away at the narrowest level that does the job. Where this lives. Studio ▸ Governance ▸ Users & Access (People · Personas · Effective policy), with the same screen at Workspace Settings ▸ Users & Access and Account menu ▸ Administration ▸ Admin ▸ Governance ▸ Users & Access.

This reference lists every role a person can hold — at platform, workspace and project level — what each one opens, which ones are protected, and how a project’s personas differ from platform roles. The narrative introduction is in Access & roles; come here when you need to know exactly what you are handing out before you hand it out.

One screen, three levels

People are managed on a single screen called Users & Access, which appears at three levels with the same header, the same master/detail layout and the same vocabulary. What changes is the tabs and how much authority the level has.

Platform    Account menu ▸ Administration ▸ Admin ▸ Governance ▸ Users & Access
            Users │ Workspaces │ Projects │ Policies
              │    hands out: Platform Admin · workspace membership · project access
              ▼
Workspace   Workspace Settings ▸ Users & Access
            Users │ Projects │ Policies
              │    hands out: Workspace Admin · Builder · Reviewer · Viewer
              ▼
Project     Studio ▸ Governance ▸ Users & Access
            People │ Personas │ Effective policy
                   hands out: Project Admin (protected) · your own personas

Two vocabularies live side by side, and it is worth keeping them apart:

A role says who administers what — the platform, a workspace, or one project.
A persona says what somebody does in one project’s workflow — Underwriter, L1-Reviewer, Claims Handler.

The Personas tab separates them on screen under the headings Project access and Personas. The About roles link in the header of any Users & Access page opens the same summary at any time.

Platform roles

Granted on the platform Users tab: pick a person, then tick the role in the Platform section of their detail pane. A confirmation appears first — “Platform roles apply across the whole platform” — and cancelling puts the tick-box back.

Role	What it covers	How it is given
Platform Admin	Runs the install: Users & Access at platform level, platform setup, language models, observability. The only platform role you can grant. Shown as a PA badge in the user list.	Tick-box on the person’s detail pane, with confirmation.
Super Admin	Botminds operations break-glass, with access across every workspace. Read-only inside the product.	Not grantable here — it is a list of email addresses set in configuration. People on it carry a Super Admin badge, and the role filter offers Super Admin (allowlist) so you can find them.
Administrator / Developer (legacy)	Two retired platform roles that are no longer handed out. People who still hold one keep working, and their chips show as read-only.	Never again. Everything Administrator opened, Platform Admin also opens; Developer never gated anything.

Watch out. Only a Platform Admin (or someone on the Super Admin list) sees the Administration ▸ Admin entry in the account menu at all, and the page refuses to open for anyone else. While you are previewing someone else’s screen with View as, your own platform powers are masked, so that entry disappears until you return to your role.

Workspace roles

Every member of a workspace holds exactly one workspace role. Change it from the Workspace role drop-down on the person’s panel in Workspace Settings ▸ Users & Access ▸ Users, or from the Workspaces section of their detail pane at platform level.

Role	What the person can do
Workspace Admin	Runs one workspace — its people, roles, projects and settings. The only workspace role that can open the workspace’s Users & Access page and set its access policies. Shown as a WA badge.
Builder	Builds in Studio: collections, agents, experiences.
Reviewer	Does review and annotation work on documents.
Viewer	Consumes only: search, chat, dashboards.

New members land on the workspace’s Default join role, chosen at Workspace Settings ▸ Users & Access ▸ Policies ▸ Defaults. It offers Viewer, Reviewer or Builder — Workspace Admin is deliberately never offered, because nobody should become an admin automatically. Promote by hand afterwards on the Users tab; the promotion asks you to confirm that “Workspace Admins can manage members, roles and all projects in this workspace”.

Watch out. You cannot change your own workspace role or remove yourself — those controls simply do not render on your own row. Workspaces tagged Platform-managed show no role drop-down and no Remove link; they are run by the platform team.

Project access — the Project Admin role

Studio ▸ Governance ▸ Users & Access ▸ Personas opens with a Project access section: one card for the Project Admin role, tagged Protected, showing how many people hold it and an Edit members button. That button opens a searchable tick-list of the project’s people with a live count line — tick, untick, Save.

Project Admin is the run-the-project role: people, personas, everything in Studio for this project. Because of that:

It cannot be renamed or deleted.
It has no collection, stage or action settings — the card offers members only, by design.
A project must always keep at least one holder. Untick everyone and Save greys out with “A project must keep at least one Project Admin.”

You can also grant or remove it from the platform Projects tab, using the ± role… drop-down beside a member (it sits in the Project access group, marked (protected)).

Who is allowed to manage a project’s people at all: a workspace admin, the project’s creator, or a holder of Project Admin. Everyone else sees the same page read-only.

Personas — your solution’s workflow roles

A persona is a role you invent for your own solution. Each one bundles the pages, actions and data that person uses in this project, and has nothing to do with platform administration. Create one with + Add persona on Studio ▸ Governance ▸ Users & Access ▸ Personas.

Field	What it does
Name	What the persona is called — e.g. `Underwriter`, `L1-Reviewer`. This name is what you pick on a lifecycle stage’s gate.
Collections	Which collections the persona covers. Your choice here decides which Stages you can then pick, because stages belong to collections.
Stages	The workflow stages this persona works in.
People	Who holds the persona. You can also set holders from the People tab of the same page.
Can view (acts as a superset of)	The personas whose work this persona may preview. The on-screen hint says it plainly: “Holders of this persona can ‘View as’ the selected personas. Leave empty for a leaf persona.” The field only appears once the project has another persona to name.
Show Advanced Settings	Opens two finer grants: a per-action picker (“Select action(s) for this role”) and content filtering by label, which narrows the persona to a slice of the documents.

Save and the Personas tab re-reads itself, so the card counts show what was actually stored.

Watch out. Deleting a persona tells you exactly who is affected first — “3 people will lose this persona, and any workflow-stage mappings will be removed”. Re-check your stage gates afterwards: a stage whose Can be viewed by ends up empty is visible to everyone. The protected Project Admin has no Edit at all — its card offers Edit members, a tick-list of the project’s people, and nothing else.

Previewing someone else’s screen — View as

Can view is what wires the preview ladder inside a project. From Account menu ▸ View as, chips let you look at the product as a lower level of access without logging out:

View as — admin roles offers Workspace Admin (“Run this workspace as its admin”) and Project Admin (“Run <project> as its admin”).
View as — personas · <project> offers the project’s personas, each with a tooltip describing what that persona sees. They only appear once you are inside a project. Admin authority — platform, workspace or project — is offered every persona there; if what you hold is a persona, you are offered the ones it declares it can view. A persona with nothing selected is a leaf, so its holders have nothing below them to preview.

Previews only go downward, and they are genuine rather than cosmetic: pages and data are limited to what the previewed role really gets, and your own admin powers are hidden for the duration. A strip at the top of the account menu reads “Viewing as <role> · Return to your role” — one click puts you back, no matter how far down you chained. Asking for a preview you are not entitled to is refused: “You can’t view as ‘<persona>’ — your role isn’t allowed to preview it.”

How personas gate lifecycle stages

This is the link to the review flows in Human-in-the-loop. A lifecycle stage has a Can be viewed by setting. The personas listed there are the only ones that can see and act on documents sitting in that stage; leave it empty and every persona can. The connection runs both ways:

On the stage — Studio ▸ Data ▸ Collections, pick the collection, open its Lifecycle tab and edit a stage: set Can be viewed by.
On the persona — the Stages field records which stages the persona is meant to work in.

So to make a stage L1-only:

On Studio ▸ Governance ▸ Users & Access ▸ Personas, use + Add persona to add L1-Reviewer — choose the collection it covers, the stages it works in, and the people who hold it.
On Studio ▸ Data ▸ Collections ▸ <your collection> ▸ Lifecycle, edit the stage and set Can be viewed by to L1-Reviewer.

A new Processing collection gives you a head start on this pattern: the seeded Four-Eyes lifecycle arrives with two review stages — L1 Review and L2 Approval — and two matching personas, L1-Reviewer (L1 Review) and L2-Approver (both review stages). The stages start open to everyone; set Can be viewed by on each one yourself, and two different people then have to confirm before a document is approved.

What a project only reads — Effective policy

A project does not set its own joining rules; it inherits them from its workspace. The Effective policy tab shows them read-only, headed “What applies here — set by workspace <name>. Ask your workspace admin to change it.” Four answers:

How people join — company sign-in only, company sign-in plus invited guests, or email invites.
Can you invite people? — “Yes — you can add users here.” or “No — your workspace admins add people.”
Can you hand out passwords? — whether one-time passwords are yours to give out. Email invites always work either way.
Defaults — the workspace’s default join role, and whether two-factor verification is required.

This tab exists so you can see why the Add-user dialog behaved the way it did without having to ask. When a rule does block you, the product always names who set it: “Set by workspace <name> ▸ Policies — ask your workspace admin.”

Taking access away

Four different actions are easy to confuse, so pick deliberately:

Action	Where	What it does
Remove from project	Project ▸ People tab	The narrowest one. “Their account and workspace access are untouched.”
Remove from workspace	Workspace ▸ Users tab, or the per-workspace Remove link at platform level	They are signed out and lose this workspace; their account survives and a Platform Admin can restore them.
Remove user	Platform ▸ Users tab ▸ ⋮	Deactivates the account and revokes every workspace. Reversible — the person shows as Suspended and Reactivate brings them back, though workspace memberships must be re-granted.
Suspend account	Platform ▸ Users tab ▸ ⋮	Blocks sign-in everywhere but keeps every membership intact. Reversible.

The Active tick-box on a project member’s panel is none of the above — it only parks that person in this project.

Rules the product will not let you break

A project must keep at least one Project Admin.
The last remaining Platform Admin cannot be suspended or removed.
A workspace must keep one Workspace Admin — the last one cannot be demoted, removed or suspended.
Project Admin cannot be renamed or deleted.
Super Admin can never be granted from inside the product.
You cannot change your own workspace role or remove yourself.
Every account action is recorded in the audit trail — see Audit & compliance.

Quick recipes

You want…	Do this
A reviewer who never opens Studio	Workspace role Reviewer, plus a persona covering the collection and the stages they review.
Someone to run one project without running the workspace	Personas ▸ Project access ▸ Edit members, tick them into Project Admin.
A team restricted to one region’s documents	In the persona, Show Advanced Settings ▸ content filtering by label.
A senior reviewer who can preview the junior queue	On the senior persona, set Can view (acts as a superset of) to the junior persona.
A final approver gate	A persona named on the last stage’s Can be viewed by, and on no other.
Someone off one project but still in the workspace	Remove from project on the project’s People tab.
Someone gone from the company	Platform ▸ Users ▸ ⋮ ▸ Remove user…