Users
Admin, Users (/admin/users), gated by the user.manage permission.
A user is somebody who signs in to the technician console. Almost always ICT staff.
A person is a student, staff member or parent, synced from your directory or student information system. People do not sign in to the console. They tap a card at the kiosk or sign in to a portal.
You manage users here. People are managed by the connectors that sync them, and viewed under people.
Creating an account
Section titled “Creating an account”Give a name, an email and one or more roles. The person is invited by email.
Build your roles first. Creating twelve accounts and then discovering the role is wrong means fixing twelve accounts.
Confirming it is you
Section titled “Confirming it is you”Anything on this screen that hands over an account — creating one, editing one, resetting somebody’s password, signing them out everywhere, deleting them, or changing which campuses they administer — asks you to confirm it is you before it runs. Answer with a code from your authenticator, a passkey, or your password, whichever your account has.
This is not about whether you have permission; you do, or the button would not be there. It is about the laptop left unlocked and signed in while you are at somebody’s desk. The confirmation lasts for that one action, not for the session.
What an account carries
Section titled “What an account carries”| Field | Notes |
|---|---|
| Name | Shown on assignments, in the audit log and on notes |
| The sign-in identifier, and where notifications go | |
| Roles | One or more. Permissions are the union of them |
| Active | Deactivating blocks sign-in without deleting history |
| Two-factor | Set up by the user themselves under Account |
Deactivating rather than deleting
Section titled “Deactivating rather than deleting”Deactivate somebody who has left. Their history stays attached to their name, so “who closed this repair in 2024” still has an answer.
Deleting an account that has done work leaves records pointing at nobody. The screen discourages it for that reason.
Deactivation takes effect immediately and revokes their refresh tokens, so they are signed out rather than remaining signed in until their session expires.
Automating the leaver problem
Section titled “Automating the leaver problem”The reliable way to end access is not to remember. Turn on SCIM provisioning and your identity provider pushes the change the moment HR disables the account, revoking every refresh token in the same transaction.
An auditor asking how deprovisioning works wants to know whether the system enforces it or whether you have a process on paper.
Single sign-on and fallback passwords
Section titled “Single sign-on and fallback passwords”With SSO configured, staff sign in with Entra or Google instead of a local password.
Keep at least one administrator with a fallback password set on their account, so an identity provider outage does not take your service desk with it. Setting it in advance saves somebody having to reach a terminal.
Users set their own fallback password under Account.
If you did not do this and everyone is now locked out, a self-hosted deployment
still has a way back: plugboard admin-reset, run on the machine itself. See
nobody can sign in. On
managed hosting, ask [email protected].
Two-factor authentication
Section titled “Two-factor authentication”Users set up TOTP themselves under Account. Scan the code with an authenticator, confirm a six-digit code, done.
Turn it on for your own account before you invite anyone else. The account with every permission should be the best-protected one.
Who can do what
Section titled “Who can do what”Permissions come from roles, and the same permissions apply everywhere. The web interface, the public API, the MCP server and the assistant all run the same checks. A user cannot do through chat or through an API key what their role forbids.
Each account shows its seat in the list and on its record: Technical, Business or Participant (free). The seat is set by the roles the account holds; nobody chooses it by hand. When a role you are granting would raise someone’s seat, the role step says so, for example “This makes Sam a Technical seat, 3 of 2 included”. It never stops the grant. See seat types for which permissions make which seat.
The Plugboard plan includes 2 Technical seats; Business seats are bought as needed. Seat counts are reported as part of the count-only telemetry a deployment sends, and going over is settled at renewal rather than blocking anything, so hiring a technician never locks the desk.