Adding users — as a Platform Admin

In one line. Users & Access at platform scope is the superset: every account, every workspace, every project — create, invite, credentials, suspension. You’ll be able to. Find any account, create people with an invite email or one-time credentials, grant the platform role, manage any workspace’s membership, and set the install-wide access rules. Where this lives. Account menu ▸ Administration ▸ Admin ▸ Governance ▸ Users & Access.

Only a platform admin sees the Admin entry in the account menu, and only a platform admin sees the Governance group inside it — Users & Access, Audit & Usage, Observability. The rails never offer a link that would refuse the person who clicks it. While you’re previewing the product as someone else with View as, your platform powers are masked off and the Admin entry disappears until you return to your own role.

The header carries + Add user, an About roles explainer — the product’s own plain-language definition of every role name on this page — and a ? link back to this guide.

Four views

Tab	What it’s for
Users	Every account on the install — the only place a person can exist before belonging to a workspace, and the only place the platform role is granted.
Workspaces	Read-only: who is in each workspace.
Projects	A workspace → project tree, where you grant and remove project access.
Policies	The install-wide rules every workspace works inside.

Finding someone

The Users list carries a search box (“Search users by name or email…”) and three filters: All roles, All statuses (Active / Suspended / Locked) and All sign-in methods (SSO / Password). Results page 25 at a time with a “Page x / y · n users” counter. On a large install a blue banner reads “Showing the first N of many users — refine your search” — narrow with search or a filter rather than paging through.

Every row has a coloured status dot:

Active — signing in normally.
Suspended — blocked from signing in until someone reactivates them.
Locked — locked out by the system after too many failed sign-ins or an expired password. Nobody suspended them. Issuing fresh credentials clears the lock.

Rows also carry badges: SSO when the person signs in through a company identity provider, Super Admin when they’re on the break-glass list, PA for Platform Admin, and Adm / Dev for the two retired legacy roles. Workspace roles are not badged on this list — they’re per workspace, so they live in the person’s detail pane.

Create a user

+ Add user → Email, Full name, and optionally a starter workspace + role so they land somewhere useful. Then pick how they get access:

Email invite — they receive a secure link and set their own password. The default; use it whenever the person has email.
One-time password — you hand it over yourself, for air-gapped or in-person hand-overs. They should change it after signing in, and the hand-over is recorded in the audit trail.

The highlighted sentence at the bottom of the dialog states exactly what’s about to happen before you confirm.

If the email already has an account, the dialog refuses at this scope: “This person already has a Botminds account — find them in Users & Access to grant access instead.” Granting more access to someone who exists is a different route — open their detail pane and use + Add access, or use the Projects tab.

Choosing the one-time password turns the dialog into a hand-over panel — “<email> added — hand over this one-time password”, the password itself, a Copy button, and the warning “Won’t be shown again. Ask them to change it after signing in.” Copy it before you close the panel; it is shown once. The person accepts the Terms & Conditions themselves at first sign-in — new accounts are created with the terms unaccepted, so the gate fires on them, not on you.

Manage an existing user

Select anyone in the Users view. The panel shows their name, email, how they sign in (SSO · <provider>, with a no password set note when they have none, or Password), their status, and a ⋮ account-actions menu. Below that:

Platform — a tick-box per grantable platform role (today, just Platform Admin). Ticking it asks you to confirm — “Platform roles apply across the whole platform” — and cancelling puts the tick-box back.
Workspaces (n) — every workspace they belong to, each with an inline role drop-down and a Remove link, plus + Add access to join them to another one. Expand a workspace row with the ▸ arrow to see the projects they hold inside it.
Legacy roles a person still holds appear as chips marked read-only — they keep working, and they can never be granted again.
Workspaces marked Platform-managed have no role drop-down and no Remove; they’re run by the platform team.

Project roles are shown here but edited from the Projects tab or inside the project itself — personas are defined in the project’s own Studio ▸ Governance ▸ Users & Access.

Exactly three items:

Generate credentials… — see below.
Suspend account (or Reactivate account when they’re already suspended) — “They will be signed out and blocked from signing in until reactivated.” Memberships stay intact.
Remove user… — “The account is deactivated and removed from all workspaces and projects. An admin can reactivate it later.”

Remove is reversible. It suspends the account and strips every workspace membership; it does not erase the person. They reappear as Suspended, and Reactivate brings the account back — though the workspace memberships have to be granted again. Neither Suspend nor Remove is allowed on the last remaining Platform Admin.

A Locked person shows Suspend account, not a reactivate option — the way to give them a working sign-in again is Generate credentials, which clears the lock.

Generate credentials

The dialog asks “How should they receive access?”:

Email reset link — an emailed secure link; the person sets their own password.
Share credentials — a one-time password you hand over yourself.

Read the warnings before you click. Share credentials warns “This replaces the user’s current password and signs them out of all active sessions” — and, when you’ve picked your own account, “This is your own account — you will be signed out too.” For someone who signs in with company sign-in, it also notes that generating a password switches on password sign-in for them.

The password appears once, in a follow-up panel with Reveal / Hide / Copy and the line “Won’t be shown again. The user has been signed out of all active sessions.” Close it and it’s gone — generate again if you lose it.

Platform roles, demystified

Platform Admin — the one grantable platform role. Runs the install: Users & Access, platform setup, LLMs, observability.
Super Admin — not a role you can grant. It’s a configured list of email addresses used by Botminds operations as break-glass, with cross-workspace bypass, changed only in platform configuration. Holders show a read-only Super Admin badge in the user list.
Administrator / Developer (legacy) — two retired platform roles that are no longer handed out. Everything the Administrator role opened, Platform Admin also opens; Developer never controlled access to anything. Accounts that still hold one keep working, and the chips are read-only.

One rule of thumb: Platform Admin runs the install, a Workspace Admin runs a workspace, a Project Admin runs a project. If you’re deciding which to give someone, give the smallest one that covers their job.

Workspaces and Projects

The Workspaces view is read-only: each workspace with its member and project counts on the left, that workspace’s members on the right. It answers “who is in this workspace” — role changes happen on the person’s own detail pane or inside Workspace settings.

The Projects view is where you change project access. Expand a workspace to reveal its projects, pick one, and you get its Members (n) with each person’s role chips and a ± role… drop-down split into Project access (the protected Project Admin, marked protected) and Personas. That picker both grants and removes: picking a role someone already holds takes it away, and either way a confirmation names the role, the person and the project.

An Add a workspace member block below lets you pick someone who is in the workspace but not yet in this project, choose a role and press Add to project. When everyone is already in, it says so and points you at + Add user for a brand-new person.

Policies — the install-wide rails

Three cards, then Save policies (greyed out until something changes).

Who can hand out passwords — how far down you’ll let workspaces hand out passwords themselves: Platform only / Down to Workspace admins / Down to Project admins, with a live line reading “Right now passwords can be handed out by: …”. This is a ceiling, not a grant: a workspace can choose anything at or above it, never below it. Tighten it and any workspace that had already delegated further loses that delegation immediately — the greyed-out options on their own Policies tab explain why.

New workspace default — what you’d like a freshly created workspace to start with: Invite-only (passwords from your team), Company sign-in only, or Self-sufficient (workspace runs its own access). Today this records your stated preference; new workspaces are still created invite-only with the platform-only password rule, and their admin sets their own rules on their Policies tab afterwards.

Always on — three facts you can’t switch off: 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.

Push it down a tier

Workspace-level administration belongs on each workspace’s own Users & Access page (G7); project-level self-management belongs to Project Admins (G6). Prefer pushing people management down to those tiers — this page is the override, not the routine.

See also: G5 · Audit & compliance — every access change here is audited.