Access & roles

In one line. How you control who can see and do what — the platform, workspace and protected Project Admin roles, 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).

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.
Member	one workspace	A workspace seat with no administration rights. A member’s actual capability — what they can see and do — comes entirely from the persona a project gives them, never from this seat.
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.

Builder, Reviewer and Viewer are retired — every seat that is not Workspace Admin is simply Member now, because the seat itself stopped deciding anything; what a member can do is set by the persona they hold in each project, not by their workspace seat. Anyone who still held one of those three sees no trace of it — their chip just reads Member, the same as everyone else’s. Two older platform roles, Administrator and Developer, are also no longer handed out; anyone who still holds one of those two keeps working and sees a read-only (legacy) chip instead. None of the five can be granted again.

Tip. Every Users & Access page carries an About access link in its header. It opens the product’s own one-screen explainer of the roles and personas 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 access, 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 ▸ 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	Managed by workspace admins, the project’s creator, Project Admins — others who reach it see it read-only

A project’s Users & Access has only the two working tabs, People and Personas — you act on both. What the project inherited from its workspace is read-only prose, so it is not a third tab to work in: it sits inside the About access panel instead (below).

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

1. 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.
2. Each workspace sets its own rules inside that ceiling — how people join, who may invite, who may hand out passwords, and whether two-factor is required. There is no default-role setting to pick: a new member always lands on the one floor seat, Member.
3. Each project reads what it inherited in its About access panel, and manages its own people and personas.

Wherever a limit bites, the product tells you who to ask. Hit it from the workspace’s own page and it names the workspace — “Set by workspace Acme ▸ Policies — ask your workspace admin.” Hit the same limit from inside a project and it says only “Set by your administrator — ask them if you need this changed” — a project has no workspace to name.

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 access        [ + Add user ]                    ?  │
│  People │ Personas                                                         │
├───────────────────────────────┼────────────────────────────────────────────┤
│  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 confirmation says it plainly — “Remove this person from the project? Their account and their access elsewhere are untouched.”
+ Add user	Opens the same Add-user dialog used at every scope (below). On the Personas tab this same button becomes + Add persona.

Changing someone’s Workspace Admin-or-Member seat is a workspace-level action, not a project one — do it from the workspace’s own Users & Access ▸ Users tab (below), not from inside a project.

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 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

1. Open Studio ▸ Governance ▸ Users & Access ▸ People and click + Add user.
2. 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.
3. Under Available personas, tick the ones they should get. If the project has none yet, the dialog says so and adds them without one.
4. 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.
5. 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 with a secure link — new accounts set their own password, existing accounts just sign in.” 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 email field is labelled Company email, a note under it reads “Company sign-in only: <your domains>. External emails cannot join,” and outside addresses are refused — everything else about the dialog (picking an existing account, ticking personas, the button) stays the same, it just never offers a delivery choice. 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 — “Adding people is handled by your administrator” — and the line below it reads “Set by your administrator — ask them if you need this changed,” never naming the workspace; from inside a project there is no workspace to name. The submit button itself reads Add user for a brand-new person and Grant access once you’ve picked someone who already has an account. 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. Every project starts with one persona already here: Member, tagged View only. It is the floor every project member falls back to when they hold nothing else, carries no grants by construction, and cannot be edited or deleted — anything granted to it would be granted to everyone in the project. Add a card per workflow role beside it (Underwriter, L1-Reviewer, Claims Handler), each showing its holder count, and Edit / Delete. A card may also show an actions count or a collection count, but only when that number is not zero: both are carried over from before their own pickers were removed from this editor, so a persona you create today shows neither, and neither is something you set here.

What a persona is made of

A persona is a name, the Stages it works in, and what it may do. There is no collapsed “Advanced” section any more — every setting shows at once:

Setting	What it does
Name	What the persona is called — use the language your business already uses (Underwriter, L1-Reviewer, Claims Handler).
Review AI results	Lets the persona correct what the AI extracted and move work onward. Two switches nest under it: creating a new label while reviewing, and re-running the AI on a document.
Assign work to people	Hands documents to people and sets their priority — its own switch, kept separate from Review on purpose, so a persona that corrects extractions does not also gain the power to hand work to other holders of the same persona.
Documents	What the persona may do with the files themselves: Add, Download, Delete.
Scope	All work or Only theirs — whether the persona sees every document or only the ones assigned to them.
Limit to	Narrows the persona further, to only the documents whose value for one field is among the values you give each holder. Leave it on Everything they can otherwise see to skip this; set a field and a collection without it shows that holder nothing.
Their edits	Whether a correction this persona makes is Final immediately, or Need review by someone else first.
Applies to workspace admins	Off by default. Switch it on and a workspace admin who also holds this persona is held to what the persona allows instead of passing through on their admin bypass — the way to give a project an owner who configures it but may not do its work.
AI allowance	A money budget (USD) this persona’s AI use may spend, on a reset period, with a choice of warning or stopping once it runs low. Leave at 0 for no limit.
Summary actions	What the persona may do with a value in the summary — approve, reject, edit, delete, comment and the like. Only takes effect once Review AI results is switched on above; clear them all to allow none.
Action pane visibility	What this persona sees on the action pane. Visibility only — clearing an item does not pause its session clock. Clear them all to show none.
Stages	Which workflow stages the persona works in.
May move into	Which stages this persona may move work in or out of. Empty means the same as Stages — set it narrower to let a persona see a stage without being able to move work into or out of it.

Who holds a persona is not set here: add or change a person’s personas from Users & Access ▸ People — select them and Edit roles — so membership is edited in exactly one place. If a persona you give them sets Limit to, a Values button appears beside Edit roles for that person — that is where you give their values for the field, one person at a time.

Save and the Personas tab re-reads itself immediately, so the card’s holder and action counts show what was actually stored. The People and Personas tabs each have their own address, so you can bookmark either one.

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. Deleting a persona takes it off every stage’s Can be viewed by, and the documents waiting in a stage it gated are not hidden: whoever the stage still lists can see them, and if it lists no one now, the stage is visible to everyone in the project. Re-check the gate after deleting a persona. So gating a stage is a two-step move:

1. Create the persona here (e.g. L1-Reviewer, covering your collection).
2. 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.

What this project inherited

A project does not get a separate tab for the policy it inherited — that would be a third thing to work on, in a screen that is otherwise two working tabs. Instead, the About access panel folds it into one more row, Effective policy, beside Project Admin and Personas. That row is a single plain-English sentence built from what the workspace actually set, for example “Email invites. You can add people here, and hand out one-time passwords. New members join as Member.” or “Company sign-in only — people from @acme.com. Only your administrator adds people, and passwords come from your administrator. New members join as Member.” Every version of the sentence ends that way: the seat a new member lands on is always named, and it is always Member — no screen sets that seat any more, and every value the stored policy can still hold is shown as Member. If you can also edit that workspace’s policy, an Edit the policy link sits right beside the sentence.

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. The dialog itself carries the real provenance line, and only when it actually blocks you: open it from a project whose workspace reserves adding people for admins, and it says “Set by your administrator — ask them if you need this changed” — never naming the workspace, because a project has no concept of one. Open the same dialog from the workspace’s own Users & Access, and it does name it — “Set by workspace Acme ▸ Policies — ask your workspace admin.”

Preview it with View as

Before you hand a solution over, look at it the way its users will. View as is an admin capability: open Account menu ▸ View as to expand a drawer with up to two groups of chips — Admin roles (the admin levels you are entitled to preview, e.g. Workspace Admin, Project Admin) and, once you are inside a project, Personas · <project name> — one chip per persona the project defines, each with a tooltip saying how many people hold it.

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, and only an admin gets to preview at all: a Platform, Workspace or Project Admin is offered every persona in the project, in addition to the admin roles below their own. A persona holder who is not also an admin gets no View as control at all — not a narrowed one, nothing — because previewing a colleague’s persona is outside what a persona exists to do. 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 answers who is in this project and carries an Add people to this project button on each project’s detail. The Policies tab is where the workspace’s real rules are set: how people join, who can invite, who can hand out passwords, and whether two-factor is required. There is no join-role picker any more — new members always join as Member, and what they can do comes from the persona a project gives them. Whatever is saved there is what a project admin sees, read-only, as the Effective policy sentence in their About access panel.

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; select one to add people who already have an account, by search.
• 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 six groups: Overview (just the Action Center), Platform (Platform Setup, White Labelling, Geo Mapping, Assistant — Piper, Types Config), AI Runtime (LLMs, Context Kernel), Extensions (MCP Servers, Skills, Skill Packs, Tools, Tool Packs, Hub Servers), Governance (Users & Access, Audit & Usage), and 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.)

1. 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.
2. Name = L1-Reviewer.
3. Under Stages, pick the review stage this persona works in (e.g. on your Invoices collection).
4. Switch on Review AI results, and add Assign work to people if this persona should also hand work to colleagues.
5. On Users & Access ▸ People, select each person who should hold it and use Edit roles to give them L1-Reviewer.
6. 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.
7. Check it without logging out, as the Project Admin who set this up: Account menu ▸ View as, open the Personas group 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, Workspace Admin, Member, the protected Project Admin) say who administers what — the platform defines them and the list never grows; a workspace Member’s real capability always comes from the persona a project gives them. 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). What a project inherited from its workspace is read-only prose in the About access panel, not a third tab.
• The platform sets a ceiling, the workspace sets the rules, the project reads what it inherited as one sentence in About access — and the Add-user dialog names who to ask whenever it actually blocks you.
• Every project starts with the floor persona Member — no grants, not editable, not deletable. A workflow persona beside it is a name, the stages it works in, and what it may do: review, assign, document actions, scope, how its edits are reviewed, an AI budget, and whether it also binds a workspace admin who holds it.
• 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 is admin-only: a Platform, Workspace or Project Admin can preview any role or persona below them, with the real limits applied and their own admin powers masked. A persona holder gets no View as at all. 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.