Workflow

Admin, Workflow (/admin/workflow), gated by the workflow.manage permission.

None of these are hard-coded enums. Statuses, priorities, coverages, repair types, loan user groups and the parts catalogue are all per-tenant data you control. So is whether several workflow features exist at all.

Do this before anyone lodges a real submission. Changing a status afterwards means deciding what happens to the submissions sitting in it.

Feature switches

The top of the page turns individual workflow features on and off. Off means the field does not appear anywhere, rather than appearing and being ignored.

Switch	What it controls
Priorities	Whether staff can set a priority on submissions
Assign technicians	Whether a submission can be assigned to a person
Staff loans	Whether loans show the staff and student distinction
Police report number	Capture a police report number on insurance jobs
Budget code	Capture a budget or cost code on submissions
Vendor repair	Whether a submission can be booked out to an external repairer

A small primary school with two technicians usually turns off priorities and assignment, because both add a click to every job and neither changes what happens. A large school with a bench and a queue wants both.

Priorities

The urgency levels. Each has a label, a colour and a rank. The rank sets the order they appear in and the order the queue sorts by.

Priorities drive SLA targets, so if you want response and resolution clocks, define priorities first and set targets second.

Statuses

The stages a submission moves through. Each has a label, a colour, a rank, and optionally an external status it maps to.

A typical set:

1. Received or Open, newly lodged and waiting to be picked up
2. Assigned or In progress, a technician owns it
3. Awaiting parts, or With vendor, blocked on something external
4. Ready, fixed and waiting for collection
5. Closed, handed back

Rename these to whatever your desk already says out loud. If your team says “on the bench”, call it that. Matching the words people already use is worth more than matching anyone’s idea of a standard.

Mapping to an external system

The external status field maps a Plugboard status onto a status in a ticketing system you also run, so a status change here can be reflected there. Set it if you run Zendesk or Web Help Desk alongside.

Ticket statuses

Tickets have their own status list, configured in the same place. The service level clock reads which statuses mean “settled”, meaning nobody is waiting on the desk. The labels, colours and order are yours; the clock behaviour follows the resolved and closed meanings rather than the words.

Coverages

Who pays. The shipped set is warranty, insurance and chargeable, and most schools keep those three.

Coverage appears to the person when they lodge a repair, so they know before they hand the device over whether this is likely to cost them anything. It is also how cost analytics splits spending, which is the number your business manager asks for.

Repair types

What kind of repair it is, and which coverage it carries. Cracked screen under insurance. Battery replacement under warranty. Liquid damage, chargeable.

These appear in the kiosk when somebody lodges, so word them the way a fifteen-year-old would recognise. “Damaged display” rather than “LCD assembly failure”.

Loan user groups

Categories a loan pool serves, such as Students, Staff or Senior School. A loan group names the user groups it is for, which pre-fills sensible defaults when a technician registers a new loan device.

Parts and prices

What technicians pick from when they record a repair outcome, and what each part usually costs.

Kept per kind of device, because an iPad screen and a laptop screen are not the same part and pretending otherwise makes the numbers useless:

Kind	Covers
Laptops	MacBooks and other notebooks
iPads	Tablets
Desktops	iMacs, towers, all-in-ones
Other	Anything else in the fleet

You start with an opinionated list rather than an empty one, priced for a school Mac fleet, because the parts list is the thing a technician meets on their first repair and an empty one sends them back to typing. Every row is yours to rename, re-price, hide or delete.

How pricing behaves

• Ticking the parts that were replaced adds their prices up into the repair’s cost.
• Typing over the total wins. A part sourced in a hurry, or supplied free under warranty, means the sum is wrong and what you type is right.
• A price change only affects repairs recorded from then on. Parts keep the price they were saved with, so last term’s numbers do not move when you update a supplier price.
• Hiding a part keeps it on the repairs that used it but takes it off the picker. This is what you want when a part is discontinued: the history stays honest and nobody picks it again.

Where these changes show up

Everything on this page flows through to:

• The kiosk, where repair types and their coverage appear when somebody lodges.
• The submissions queue, where statuses and priorities are the filters.
• Cost analytics, which groups by type and coverage.
• SLA targets, which are set per priority.
• Automation rules, whose conditions match on type, priority and coverage.
• Reports.

Which is why doing it first saves work. Every one of those places refers back to these definitions.

Changing things later

Renaming is safe. A label change updates everywhere, and history keeps its meaning because records reference the key instead of the words.

Deleting is not. Deleting a status leaves submissions pointing at something that no longer exists. The screen will warn you and, where possible, refuse. Prefer disabling: a disabled entry stops appearing in pickers but keeps working on records that already use it.