Adding users — as a Workspace Admin

In one line. Users & Access is your one page for everyone in the workspace: add people, set roles, see which projects they’re in, remove them — and set the rules everyone else works inside. You’ll be able to. Add a person by email invite or one-time password, change a workspace role, read who is in which project, and set how people join your workspace. Where this lives. Workspace ▸ Users & Access — the settings gear on your workspace home (the project list).

The workspace rail has exactly three entries: General, Users & Access, Audit & Usage. Only Workspace Admins see the last two — a Builder, Reviewer or Viewer doesn’t get the menu entry, and a direct link is turned away.

The page you’re on

Three tabs sit under the title:

Tab	What it’s for
Users	Everyone in the workspace, and what each of them holds.
Projects	Read-only: which projects exist and who is in them.
Policies	The rules for joining, inviting and passwords across this workspace.

The header carries + Add user, an About roles explainer, and a ? link to this guide. When your plan sets an allowance, a licence strip reads Licenses allowed / Used / Available.

If a blue banner says some project memberships couldn’t be read just now, the Projects column is incomplete — the people are still there. Reload to retry.

Add a person

Press + Add user. It’s the same dialog used at every scope, and it reshapes itself to the rules you set on the Policies tab.

1. Email. Type the address.
2. Workspace role. This box is read-only here — it shows your workspace’s default join role, e.g. Viewer (workspace default). Change their role afterwards from their detail pane on the Users tab.
3. How do they get access? Choose one:
   • Email invite — they set their own password via a secure link. Nothing to share.
   • One-time password — you hand it over yourself; they should change it after signing in. Recorded in the audit trail.
   • If your workspace doesn’t hand out passwords, the second option is replaced by a line naming who does. Email invites keep working either way.
4. Read the sentence. The line at the bottom states exactly what will happen, e.g. “jane@acme.com will join workspace Acme as Viewer — they receive an email to set their own password — there are no passwords to share.” Confirm.

An email that already exists vs a brand-new one

A brand-new email creates the account and joins it to this workspace in one step. An email that already has an account is not duplicated — that person is simply added to this workspace with the default join role.

If you chose the one-time password

The dialog becomes a hand-over panel with the password, a Copy button and the warning “Won’t be shown again. Ask them to change it after signing in.” Copy it before closing — there is no second chance; you’d have to issue a fresh one.

Everyone accepts the Terms & Conditions themselves at first sign-in. You can’t accept for them.

If your workspace uses company sign-in

With Company sign-in only, the field is labelled “Person (from your identity provider)”, a note names the allowed domains, the delivery choice disappears, and the button reads Pre-assign — the person gets their access the moment they first sign in. Outside emails cannot join, and that is enforced by the platform itself, not just hidden in this form.

With Company sign-in + invited guests, your own domains join automatically on first sign-in and the dialog explains that this particular invite is for a named outside guest.

Manage someone already in the workspace

Select them in the Users list. Their panel shows:

• Workspace role — a drop-down offering Workspace Admin, Builder, Reviewer, Viewer. Promoting someone to Workspace Admin asks you to confirm: “Workspace Admins can manage members, roles and all projects in this workspace.”
• Projects in this workspace — each project with the roles they hold there, plus a Manage projects link to change which projects they belong to.
• Account — 2FA verified: Yes/No, with a button to de-activate or re-activate two-factor verification for that one person.
• Remove from workspace — warns “They are signed out and lose access here, but their account survives — a Platform Admin can restore them.”

You cannot change your own role or remove yourself: those controls simply don’t render on your own row.

Someone who has been added but hasn’t signed in yet shows as Invited / Pending rather than Active.

Removing, suspending, reactivating

Three different removals exist, and they’re worth keeping straight:

1. Remove from project (inside a project) — account and workspace access untouched.
2. Remove from workspace (here) — signed out, loses this workspace, account survives.
3. Remove user (platform only) — deactivates the account and revokes every workspace. Reversible.

Suspending an account blocks sign-in everywhere while keeping every membership intact, and reactivating undoes it. Even when you’ve delegated that to workspace admins on the Policies tab, the suspend and reactivate buttons live on the platform Users & Access page today — ask the platform team rather than hunting for a button here. From your page, Remove from workspace is the action that takes someone’s access away.

The Projects tab is read-only

It answers “who is in this project”, nothing more. The page tells you where to go instead: open the person on the Users tab and use Manage projects, or use + Add user inside the project’s own Studio ▸ Governance ▸ Users & Access page.

Policies — the rules for your whole workspace

This tab is the heart of the job. Four panels, then Save policies at the bottom — it stays greyed out until you actually change something, and after saving it re-reads what was really stored, so if the platform caps a choice you’ll watch the setting snap back to the allowed one.

How people join

• Company sign-in only — “Only people from your company sign-in can join.” Greyed out until company sign-in is actually connected, with the note “Connect your company sign-in first to use this option.”
• Company sign-in + invited guests — your company joins automatically; named guests may be invited.
• Email invites — anyone your admins invite gets an email to set their own password.

A plain-English consequence line under the group updates as you pick.

Who can invite people

• Workspace admins — project admins manage existing members only.
• Workspace + Project admins — project admins can bring in their own people.

This governs bringing a brand-new person into the workspace. It never takes away a Project Admin’s ability to give an existing member a role in their own project.

Choosing Workspace admins in a workspace that currently has no Workspace Admin is refused — that stops a workspace locking itself out of ever adding anyone. When invites are reserved for you, a Project Admin who presses + Add user sees a block panel naming your workspace and pointing at this tab.

Who can hand out passwords

Platform only (the safest default) · Workspace admins · Workspace + Project admins. Options deeper than your plan permits are greyed out with “Your Botminds plan limits how far this can go.” If the platform tightens that limit later, the tighter rule applies straight away. Email invites always keep working whatever you choose.

Defaults

• Default join role — the workspace role a newcomer lands on: Viewer, Reviewer or Builder. Workspace Admin is deliberately not offered; nobody joins as an admin automatically. This drop-down is what the Add-user dialog shows greyed out.
• Workspace admins can suspend and reactivate people who exist only in this workspace — a tick-box. It only ever covers accounts that belong to this workspace and nowhere else; someone who is also in another workspace stays a platform-level account.
• Require 2FA for all members — everyone must complete two-factor verification before they can use the workspace. Saving the workspace General page can still reset this, so re-check the box here after a General save.

These three settings moved. The two-factor requirement, whether Project Admins may invite, and the role people join as all used to sit on Workspace ▸ General. They’re edited only here now. General keeps the workspace name and web address, Enable Project Restore, and the read-only plan facts.

Whatever you save here is exactly what a Project Admin reads, read-only, on their Effective policy tab — so they can see the rule and who to ask without messaging you.

See also: G6 for project-level administration · G1 · Access & roles for the role model.