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.
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 merely have a process.
Single sign-on and fallback passwords
Section titled “Single sign-on and fallback passwords”With SSO configured, staff sign in with Entra or Google rather than a local password.
Keep at least one administrator with a fallback password set on their account. An identity provider outage should not be an outage of your service desk, and setting this up afterwards is not possible by definition.
Users set their own fallback password under Account.
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, not the one nobody got round to.
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.
Licence limits
Section titled “Licence limits”Plans include a number of technician accounts:
| Tier | Included technician accounts |
|---|---|
| Core | 3 |
| Standard | 8 |
| Advanced | 20 |
| Enterprise | Negotiated |
The count is reported as part of the count-only telemetry a deployment sends, and going over accrues overage rather than blocking anything. Nobody gets locked out of a service desk because they hired a technician.