Users & roles

Users & roles

Three things determine what someone can do in the platform:

1. User — their identity (email, login)
2. Roles — what kinds of action they’re authorised for
3. Departments — what scope they care about

A user with the helpdesk::agent role + the IT department sees IT tickets and can act as an agent on them. The same role assigned to the same user but with the Estates department instead would scope them to Estates tickets.

Standard roles

The seeded role catalogue:

• Platform admin — workspace creation, user management, mail/SSO settings; everything
• Workspace admin — workspace settings, role assignments, branding; not platform-wide
• Helpdesk admin — configure the helpdesk (SLAs, automation, types, etc.)
• Helpdesk agent — work tickets in their dept(s)
• Helpdesk requester — raise tickets via the portal; the default for any user
• Estates admin / agent — same split for the Estates module
• Assets admin / agent — same for Assets
• Governance admin / agent — same for Governance
• SCR admin / agent — same for SCR
• DSL — designated safeguarding lead; sees pupil-safeguarding data
• DPO — data protection officer; sees personal-data audit logs
• Finance lead — sees cost / budget data on catalogue items + assets
• HR lead — sees personal data on staff records

Custom roles

Trusts add custom roles when the standard ones don’t fit. Examples:

• Pastoral lead — DSL minus some of the operational permissions
• MAT IT director — agent across all academies, with cross-academy reporting
• Year-group lead — pastoral access scoped to one year group

Custom roles are built by combining permissions from the catalogue. You don’t write code; you tick boxes.

Permissions

Permissions follow a module::action naming convention:

• helpdesk::ticket::create, helpdesk::ticket::update, helpdesk::ticket::delete
• assets::asset::view, assets::asset::manage
• governance::risk::review
• scr::record::sign-off

Most users don’t see permissions directly — they see the role names. Permissions are for the workspace admin building or auditing roles.

Departments

Independent of roles. A user with the helpdesk::agent role and three department assignments (IT, Estates, HR) can work in all three queues. Removing the IT department doesn’t remove the role; it removes the scope.

Departments aren’t security boundaries (an agent can still flip the queue filter to “All” if they have permission). They’re defaults — “this is what’s normally relevant to you”.

Adding a user

Three paths:

1. Manual — admin creates the user with name + email; the user gets an invite email with a magic link to set up their password (or auto-redirected to SSO)
2. SSO + JIT provisioning — when SSO is configured, users auto-create on first login with the role + departments mapped from their IdP groups
3. Bulk import — CSV with email, name, role, dept(s); useful at term-start for a batch of new staff

Removing access

Don’t delete users; deactivate them. The audit log needs the user reference for past actions. Deactivated users can’t log in but their history stays attributed.

When someone genuinely leaves the trust, deactivate. When they switch roles within the trust, change their roles + departments instead.