The Users section lists the users of every workspace on the deployment in one place, so a super admin can fix an account without entering the workspace. Day-to-day team management still belongs to each workspace's own administrators; the console is for provisioning first admins and for support.
Where to find it
Users in the console sidebar (/admin/users), for console roles holding Users view; every change needs Users Act.
The list
The list shows users and pending invitations across all workspaces (deleted workspaces are left out). Pending invitations come first, then users from newest to oldest, 50 per page.
Filter by:
- Search — email or name
- Workspace
- Role
- Status — Active, Disabled, or Pending (an invitation not yet accepted)
Each row shows the user, their workspace, role, status, and whether the account has been activated.
Super admins' own accounts inside workspaces (see Entering a workspace) never appear here.
Inviting a user
Invite user opens a dialog: choose a workspace, then enter the email, full name and role. The role list holds that workspace's own roles (including any it created) plus the portal types Employee, Candidate and Trainer. Inviting an Employee also needs a Position in that workspace. The list's role column and filter use the workspace roles too.
Only an Owner can make someone a Workspace Admin, or give a workspace role that manages users and roles. Other console roles with Users Act also can't change, disable, remove, reset or re-invite a Workspace Admin.
The invitee receives the usual invitation email with a 7-day activation link. Inviting the same email again to the same workspace replaces the earlier pending invitation, so only the newest link works.
Actions on a user
From a user's row:
- Change role — move the user to another back-office role, or to Employee (only if they are linked to a person record). Candidate and Trainer accounts are tied to their records and cannot be switched to or from; invite again instead.
- Disable account / Enable account — a disabled user cannot sign in, and any session they have ends on their next request. Their data is untouched.
- Send password reset — emails them a reset link. Only for enabled users in active workspaces.
- Reset two-factor — for a user who lost their authenticator app (for example the only Workspace Admin of a workspace). It removes their app and trusted devices, ends their sessions, and emails them; they set two-factor up again at their next sign-in. Their password does not change. Shown only for users who have two-factor set up. The Two-factor column shows each user's status (Authenticator app, Not enrolled; "—" for candidates and invitations).
- Remove account… — removes the user from the workspace, with the same rules as removing a member inside the workspace.
On a pending invitation: Resend issues a fresh link and invalidates the old one.
A role change signs the user out of every open session on their next request; they sign in again and work under the new role (including its two-factor rule).
The last-admin rule
A workspace must always keep a real Workspace Admin. The console refuses to move, disable or remove the last active Workspace Admin of a workspace. Super admins' hidden accounts never count as that administrator.
Bulk loading
The console does not bulk-load users. After the first admin is active, the workspace's own administrators invite their team and bulk-load employees with the in-app tools (see Data editor).