Roles and permissions

Admin, Roles (/admin/roles), gated by the role.manage permission.

A role is a named set of permissions. Users hold one or more roles, and their effective permissions are the union.

A role holding * is a superuser within its tenant. Not across tenants: there is no permission anywhere that crosses a tenant boundary.

Build roles first

Create the roles, then create the users. Doing it the other way means editing every account when you realise the role was wrong.

Roles that match a school desk

A shape that works for most schools:

Role	Holds	For
Administrator	*	You, and one other person
Technician	View and update everything operational; issue and return loans; create, update and close repairs and tickets; view costs	Your day-to-day staff
Senior technician	Technician, plus device.manage, directory.manage, charge.approve, report.manage	Whoever is trusted with MDM commands and money
Front desk	loan.view, loan.issue, loan.return, repair.view, repair.create, client.view, stock.manage	A counter that hands things out but does not fix them
Read only	The .view permissions	A head of department who wants visibility

The front desk role is the one worth building even in a small school. It is what lets you put a student helper or a casual on the counter during the first week of term without giving them the directory or the audit log.

The full permission list

Loans

Permission	Allows
loan.view	See loans and who has what
loan.issue	Issue a loan device to somebody
loan.return	Mark a loan returned
loan.manage	Register devices, edit, bulk actions, manage loan groups

Devices and inductions

Permission	Allows
device.view	See device records and their history
device.manage	Send MDM commands: lock, wipe, restart, clear passcode
induction.manage	Run inductions, import rosters, record issued devices

Repairs

Permission	Allows
repair.view	See submissions
repair.create	Lodge one
repair.update	Change status, priority, assignment, notes
repair.close	Close one, and record its outcome and cost

Tickets

Permission	Allows
ticket.view	See tickets
ticket.create	Raise one
ticket.update	Change status, queue, assignment
ticket.comment	Reply to the requester
ticket.internal	Read and write internal notes
ticket.close	Close one

ticket.internal is split out on purpose. An internal note is where somebody writes “third time this term, escalate” or “her mother rang, do not put this in writing”. Separating it means a school can hand a casual the queue without handing them that.

Stock and money

Permission	Allows
stock.manage	Maintain the product catalogue and sell items
cost.view	See cost analytics
cost.export	Export cost data
charge.view	See damage charges
charge.raise	Propose a charge against a family
charge.approve	Approve, decline or waive a charge

Damage billing is split across two people on purpose. A technician who can propose a charge must not be able to make it real, and the person who decides a family pays is the same person who can decide they do not, so waiving sits with approval rather than with raising. See damage charges.

People and directory

Permission	Allows
client.view	See people and their profiles
client.manage	Edit person records, register cards
directory.view	Search the identity provider
directory.manage	Change licences, lock accounts, delegate inboxes, reset passwords

Administration

Permission	Allows
user.manage	Create and deactivate staff accounts
role.manage	Create roles and change what they hold
connector.manage	Configure connectors and their credentials
branding.manage	Change name, logo and colours
feature.manage	Enable and disable modules
workflow.manage	Statuses, priorities, types, coverages, parts
billing.manage	Enter or remove a licence key
integration.manage	Issue API keys and manage webhooks
audit.view	Read the audit log

Operations

Permission	Allows
monitor.view	See service monitors
monitor.manage	Create and configure monitors
backup.view	See backup history
backup.manage	Schedule, run and verify backups
kb.manage	Write and publish knowledge base articles
report.view	Run reports
report.manage	Create and schedule reports

Permissions apply everywhere

The same checks run on every surface:

• The web console.
• The public REST API, scoped to the API key.
• The MCP server, where a key without a permission does not even see the corresponding tool in tools/list.
• The assistant, which can only do what the signed-in user’s role allows.

There is no ambient administrator and no back door for an integration. An API key is a set of scopes, and it cannot exceed them.

Two to be careful with

device.manage allows wipes. That command destroys a student’s data and cannot be undone. Give it to the people who should have it and no one else.

directory.manage allows password resets and mailbox delegation in your identity provider. It is effectively an account takeover capability, which is why Plugboard lets every directory action be attached to a ticket so there is a record of why it happened.

Auditing

Every permission-gated action is written to the audit log with who did it, when, and what changed. Reviewing that log once a term tells you which permissions are actually being used, which is usually different from what people asked for.