Access & roles

In one line. How you control who can see and do what — the platform and workspace roles, the protected Project Admin role, and the personas your solution defines and gates its workflow stages with. You’ll be able to. Tell a role from a persona, add someone to a project, build a persona, gate a lifecycle stage to it, and preview the result with View as. Where this lives. Studio ▸ Governance ▸ Users & Access (People · Personas · Effective policy).

Why access control matters

A solution that works is only half-built; a solution other people can be trusted to run is finished. On this platform, access does two jobs:

It decides what you see. Your role decides which buttons, fields and Studio pages appear at all. If a colleague cannot see a button, it is nearly always access they have not been given, not a bug.
It decides what you may act on. Personas decide who may work on a document at each stage of its review flow. This is how “AI recommends, two humans confirm” actually gets enforced (D3 · Taxonomy, lifecycle, tags & events).

The third leg — the record of who did what — is the audit trail, covered in G5 · Audit & compliance.

Two vocabularies: roles and personas

This is the one distinction worth learning properly, because the product keeps the two apart everywhere it shows them.

A role answers who administers what. Roles come from the platform. There is a fixed, short list of them and you cannot invent new ones.
A persona answers what job this person does in this solution. Personas are yours: you name them (Underwriter, L1-Reviewer, Claims Handler), you decide what each one covers, and they exist only inside the one project that defines them.

The roles, top to bottom:

Role	Scope	What it runs
Platform Admin	the whole install	Users & Access, platform setup, language models, observability. The only platform role anyone can grant.
Super Admin	the whole install	Botminds operations break-glass. Not a role you can hand out — it is a list of email addresses set in configuration, and it is read-only inside the product.
Workspace Admin	one workspace	Its people, roles, projects and settings.
Builder	one workspace	Builds in Studio: collections, agents, experiences.
Reviewer	one workspace	Review and annotation work on documents.
Viewer	one workspace	Consumes only: search, chat, dashboards.
Project Admin	one project	Its people, its personas, everything in Studio. Protected — it cannot be renamed or deleted, and a project must always keep at least one holder.

Two older platform roles, Administrator and Developer, are no longer handed out. Anyone who still holds one keeps working and sees it as a read-only chip; you cannot grant either again.

Tip. Every Users & Access page carries an About roles link in its header. It opens the product’s own one-screen explainer of the roles in play at that level — the wording there is the canonical one, so use it when you brief a colleague.

One page, three scopes

Users & Access is deliberately the same screen wherever you open it: the same header (title, About roles, one primary button, a ? link to the guide for that scope), the same list-and-detail layout, and the same plain-English sentence before anything is added. What changes is the tabs and how much authority you have.

Where you open it	Path	Tabs	Who can open it
Platform	`Account menu ▸ Administration ▸ Admin ▸ Governance ▸ Users & Access`	Users · Workspaces · Projects · Policies	Platform Admins
Workspace	`Workspace home ▸ settings gear ▸ Users & Access`	Users · Projects · Policies	Workspace Admins
Project	`Studio ▸ Governance ▸ Users & Access`	People · Personas · Effective policy	Managed by workspace admins, the project’s creator, Project Admins — others who reach it see it read-only

The three scopes form an authority ladder, and it is worth stating plainly:

The platform sets a ceiling — how far down it will let workspaces hand out passwords themselves, and what it prefers a new workspace to start with.
Each workspace sets its own rules inside that ceiling — how people join, who may invite, who may hand out passwords, the default role newcomers land on, and whether two-factor is required.
Each project reads what it inherited on Effective policy, and manages its own people and personas.

Wherever a limit bites, the product tells you who set it and who to ask — “Set by workspace Acme ▸ Policies — ask your workspace admin.”

The People tab

Studio ▸ Governance ▸ Users & Access ▸ People — everyone in this project, with a status dot and their persona chips. A search box filters by name or email. Select someone and their detail opens on the right.

┌───────────────────────────────┬────────────────────────────────────────────┐
│  Users & Access   About roles         [ + Add user ]                    ?  │
│  People │ Personas │ Effective policy                                      │
├───────────────────────────────┼────────────────────────────────────────────┤
│  Search people by name or e…  │   Amy Anderson                             │
│  ● Amy Anderson           <───┤   amy@acme.com                             │
│      L1-Reviewer   QA         │                                            │
│  ● Bob Brown                  │   Personas & access (2)                    │
│      Project Admin            │     [ L1-Reviewer ]  [ QA ]                │
│  ● Chris Cole                 │                                            │
│      No role assigned         │   [x] Active                               │
│  …                            │                                            │
│                               │   Manage   Edit roles · Remove from project│
└───────────────────────────────┴────────────────────────────────────────────┘

What every control does

Control	What it does
Personas & access	The personas this person holds here, plus Project Admin if they have it. Change them with Edit roles. Someone with nothing yet shows No role assigned.
Active	Switches this person’s membership of this project on or off. It is not the same as suspending their account — it only parks them here.
Edit roles	Re-opens the persona picker for this person.
Remove from project	Takes them out of this project only; the warning says it plainly — their account and workspace access are untouched.
Workspace role	A drop-down that changes their role across the whole workspace, from inside the project. Project Admins get it while the workspace lets project admins bring in their own people; it disappears when the workspace reserves invites for its own admins.
+ Add user	Opens the same Add-user dialog used at every scope (below). On the Personas tab this same button becomes + Add persona.

The add, edit and remove controls only appear if you actually run this project — a workspace admin, the project’s creator, or a Project Admin. Everyone else sees the same screen, read-only.

The status dot on a project row means Active or Inactive — this is membership of the project, not the state of the account. Account-level states show on the wider pages: the platform list adds Suspended (blocked from signing in until reactivated) and Locked (locked out after too many failed sign-ins or an expired password), and workspace lists add Invited / Pending — added, but has not signed in yet. Locked is not the same as suspended — nobody did it to them, the system did; issuing fresh credentials clears it.

Add someone to the project

Open Studio ▸ Governance ▸ Users & Access ▸ People and click + Add user.
Type the email. A brand-new email creates the account and adds them here in one step; an email that already has an account is not duplicated — the existing person is simply added to this project.
Tick the personas in this project they should get. If the project has none yet, the dialog says so and adds them without one.
Choose how they get access — an email invite (they set their own password through a secure link) or a one-time password you hand over yourself.
Read the sentence at the bottom. It spells out exactly what is about to happen — “jane@acme.com will join this project as Underwriter — they receive an email to set their own password, there are no passwords to share.” Then confirm.

Watch out. The dialog reshapes itself to your workspace’s rules, and it says so rather than failing silently. If the workspace runs on company sign-in only, the field becomes Person (from your identity provider), the delivery choice disappears, and the button reads Pre-assign — the person gets the access the moment they first sign in; outside emails cannot join. If one-time passwords are reserved for a higher level, that option is replaced by a line naming who can hand them out, and email invites keep working. If adding people altogether is reserved for workspace admins, the dialog opens on a block message naming the workspace to ask. A one-time password is shown once, in a panel that says so — copy it before you close it.

The Personas tab

Studio ▸ Governance ▸ Users & Access ▸ Personas — this is the security surface that matters most, and it is split into two clearly separated sections, exactly as the two vocabularies are.

Project access — who runs this project. One card, for the protected Project Admin role, tagged Protected, showing how many people hold it and an Edit members button. That is all it offers: no collections, no stages, no actions. By design it is the run-the-project role, so only its membership changes. Edit members opens a tick-list of the project’s people with a live count; a project must keep at least one Project Admin, so unticking everyone greys out Save.

Personas — your solution’s workflow roles. One card per persona with its holder count, how many collections and actions it covers, and Edit / Delete. Empty state: No personas yet — add one for each workflow role in your solution.

What a persona is made of

A persona is a name, plus the Collections it covers, the Stages it works in, the people who hold it, and a Can view setting. Show Advanced Settings adds the specific actions it may take and the content it is limited to.

Field	What it does
Name	What the persona is called — use the language your business already uses (Underwriter, L1-Reviewer, Claims Handler).
Collections	Which collections this persona works in. Choosing them narrows the Stages list to those collections’ stages.
Stages	Which workflow stages the persona works in.
People	Who holds the persona. You can leave this empty and assign holders later.
Can view (acts as a superset of)	The personas whose work this one may preview with View as. Leave it empty for a leaf persona — its holders have nothing below them to preview.
Select action(s) for this role	Advanced. The specific things this persona may do.
Content filtering by label	Advanced. Narrows what the persona sees to documents whose label matches a value.

Save and the Personas tab re-reads itself immediately, so the card’s holder, collection and action counts show what was actually stored.

The People and Personas tabs each have their own address, so you can bookmark either one; Effective policy opens in place.

Watch out. Delete on a persona tells you exactly who is affected before it goes — “3 people will lose this persona, and any workflow-stage mappings will be removed.” Removing the mappings is the part people forget: a stage that is no longer restricted to anyone becomes visible to everyone in the project. Re-check your stage gates after deleting a persona.

How personas gate lifecycle stages

A lifecycle stage has a Can be viewed by setting. The personas you list there are the only ones who can see and act on documents resting in that stage; leave it empty and everyone in the project can. So gating a stage is a two-step move:

Create the persona here (e.g. L1-Reviewer, covering your collection).
On the stage, set Can be viewed by to that persona.

Every new Processing collection starts on the Four-Eyes flow, and it hands you the first half of that move already done: two personas are created alongside the lifecycle — L1-Reviewer, which works the L1 Review stage (the first human eye), and L2-Approver, which works both review stages, so the approver can see what L1 saw before signing off. The second half is yours. The stages themselves start open to everyone in the project; you narrow them by setting Can be viewed by on each one, which is exactly the exercise at the end of this page.

Stages live inside a collection, not in the menu: Studio ▸ Data ▸ Collections, pick the collection, open its Lifecycle tab.

The Effective policy tab

Studio ▸ Governance ▸ Users & Access ▸ Effective policy — a read-only summary of the access rules this project inherited, headed “What applies here — set by workspace Acme. 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 available to you when you add someone. When they are not, email invites still work fully.
Defaults — the role new members join as, and whether two-factor is required.

Nothing here is editable at project level, on purpose. It exists so you can see why the Add-user dialog behaved the way it did without having to ask — and it names the workspace to ask when you do need it changed.

Preview it with View as

Before you hand a solution over, look at it the way its users will. Account menu ▸ View as offers chips for the admin roles you are entitled to preview (Workspace Admin, Project Admin), and — once you are inside a project — View as — personas, one chip per persona, each with a tooltip describing what that persona sees.

The preview is genuine, not cosmetic: pages and data are limited to what that role really gets, and your own admin powers are masked while it is on, so the Administration entry disappears from your menu until you come back. Previews only ever go downward. Admin authority — platform, workspace or project — is offered every persona in the project; if what you hold is a persona rather than an admin role, the chips you get are the ones its Can view setting names, and a persona you are not entitled to preview is refused by name. A strip at the top of the account menu reads “Viewing as … · Return to your role”, and that one click always brings you straight back, however far down you chained.

Three ways to take access away

They are easy to confuse and they are not interchangeable:

Action	Where	What it does
Remove from project	project People tab	Out of this project only. Account and workspace access untouched. The narrowest of the three.
Remove from workspace	workspace Users tab, or the per-workspace Remove link on a person’s platform detail	Signed out and loses this workspace. The account survives and a Platform Admin can restore them.
Remove user	platform Users tab only	Deactivates the account and revokes every workspace. Reversible — they show as Suspended and Reactivate brings them back, though the workspace memberships have to be granted again. Never allowed on the last Platform Admin.

Suspend sits alongside all three: reversible, blocks sign-in everywhere, and leaves every membership intact.

Above the project

The same page at the two wider scopes is where accounts themselves are created and platform roles are granted.

Workspace — Workspace home ▸ settings gear ▸ Users & Access. The Users tab lists everyone in the workspace with their workspace role, and lets you change that role, manage which projects they are in, switch two-factor off or back on for one person, or remove them from the workspace. The Projects tab is read-only — it answers who is in this project. The Policies tab is where the workspace’s real rules are set: how people join, who can invite, who can hand out passwords, and the defaults (join role, two-factor). Whatever is saved there is what a project admin sees, read-only, on their Effective policy tab.

Platform — Admin ▸ Governance ▸ Users & Access. This is the answer to the question every access review starts with: who can get into what, right now? Four views:

Users — every account on the install, searchable, with filters for role, status and sign-in method. That last filter is the one every company sign-in rollout ends on: it isolates exactly the password-only accounts. Each person’s detail shows their platform role, every workspace they belong to, and — expanding a workspace — the projects and personas they hold inside it. The ⋮ menu on a person recovers a locked-out or bounced-invite account on the spot with Generate credentials… (email them a reset link, or hand over a one-time password shown exactly once, which signs them out everywhere), and carries Suspend account and Remove user….
Workspaces — who is in each workspace. Read-only.
Projects — a workspace-and-project tree; pick a project and grant or take away Project access and Personas for its members, or add an existing workspace member to it.
Policies — the install-wide rails: how far down passwords may be handed out, what a new workspace should start with, and the three things that are always on (the Super Admin list is set in configuration and can never be granted here, every account action is recorded in the audit log, and admins can only manage accounts inside their own scope).

Note. Administration does not open on a page catalogue — it lands on the Action Center, a self-clearing to-do list of setup gaps, incidents and access risks (a last-admin-standing warning is one of its checks). Its left-hand menu has four groups: Platform (Action Center, Platform Setup, White Labelling, Piper, Types Config), AI Runtime (LLMs, Context Kernel), Extensions (MCP Servers, Skills, Skill Packs, Hub Servers), and Governance (Users & Access, Audit & Usage, Observability).

Try it yourself

Create an L1-Reviewer persona and gate a review stage to it. (Assumes a Processing collection with a lifecycle — e.g. the one from UC · Invoice processing.)

Go to Studio ▸ Governance ▸ Users & Access ▸ Personas. If L1-Reviewer is already there — it comes with the Four-Eyes flow — click Edit on it and skip to step 3. Otherwise click + Add persona.
Name = L1-Reviewer. Under Collections, pick your collection (e.g. Invoices).
Under Stages, pick the review stage this persona works in.
Click Show Advanced Settings and grant the actions a first-line reviewer needs. Leave Can view empty — a first-line reviewer previews nobody.
Add the people who hold it, and save.
Now open Studio ▸ Data ▸ Collections, pick the same collection, open its Lifecycle tab, edit the L1 Review stage and set Can be viewed by = L1-Reviewer. Save.
Check it without logging out: Account menu ▸ View as — personas and pick L1-Reviewer. Documents at L1 Review are visible and actionable; everything that persona was not given is not. Return to your role when you are done.

Recap

Roles (Platform Admin, the four workspace roles, the protected Project Admin) say who administers what — the platform defines them and the list never grows. Personas are your solution’s own workflow roles inside one project.
One page, Users & Access, at three scopes: platform (Users · Workspaces · Projects · Policies), workspace (Users · Projects · Policies), project (People · Personas · Effective policy).
The platform sets a ceiling, the workspace sets the rules, the project reads Effective policy — which always names the workspace to ask.
A persona is a name plus collections, stages, holders, a Can view setting, and — under Show Advanced Settings — its actions and content filter. Personas gate lifecycle stages through Can be viewed by; deleting one removes those mappings, so re-check the stage.
Project Admin is protected: no rename, no delete, and a project must always keep at least one holder.
View as previews any role or persona below you, with the real limits applied and your own admin powers masked. One click returns you.

Where to go next

G6 · Adding users — Project Admin · G7 · Workspace Admin · G8 · Platform Admin — the step-by-step guide for whichever seat you sit in.
D3 · Taxonomy, lifecycle, tags & events — the stage model and the Can be viewed by gate personas plug into.
G5 · Audit & compliance — the trail that proves who did what.
G3 · Policy & guard rails — the soft-governance layer that sits on top of hard access control.
R5 · Roles & personas reference — the field-by-field reference for every role and persona setting.