Submissions

/repairs, and /repairs/<id> for one. Needs module.repairs.

A submission is a repair: somebody’s device needs work. It carries the device, the problem, the person, its status, and what it cost.

Named “submission” rather than “repair” because that is what schools using the original system called it, and the word stuck.

The queue

The list is your work queue.

Filter by status, priority, assignment and coverage to focus it. The filters people use most are Open, Overdue and Unassigned, in that order.

Search for a submission, a serial or a person.

Create a submission for a walk-up, choosing the person, the device, the repair type and whether a loan is needed.

The queue arrives fifty at a time, newest first, with the total above the table and Previous/Next beneath it once there is a second page. Open means every status but Closed, and the server decides that — so the count is your whole open queue, not the rows currently on screen.

Overdue items, meaning past their SLA target, are flagged so they stand out.

Where submissions come from

Source	How
The kiosk	A student or staff member lodges it themselves
The desk	A technician creates one for a walk-up
The assistant	“Create a damaged display repair for Riley Brooks with a loan”
The API	Your own integration

Kiosk-lodged submissions arrive with a sticky toast, so they are not missed.

The lifecycle

A submission moves through statuses and carries a priority. Both are yours to define; what follows is a typical shape.

1. Received. Newly lodged, waiting to be picked up.
2. In progress. A technician owns it and is working.
3. Awaiting parts or With vendor. Blocked on something external.
4. Ready. Fixed and waiting for collection.
5. Closed. Handed back.

The progress strip

Across the top of every repair, a strip folds the statuses into six stages that read the same on every repair:

Stage	Statuses it covers, by their default names
Received	Pending
Booked	Booked
In repair	In progress, At vendor, Parts required, Parts received
Awaiting client	Awaiting approval, Awaiting payment
Ready	Ready for collection
Collected	Closed

The current stage shows the exact status and how long the repair has been in that stage. Earlier stages show the date they were entered. Dates come only from recorded status changes: a stage nobody recorded entering shows no date rather than a guess. Awaiting client is only needed for some repairs, so a repair that went straight past it shows it as Not needed.

Working one

Open a submission to see the device, the reporter, the problem, the full history, and the actions your permissions allow.

The page reads in order. Under the progress strip, one banner names the next step, such as marking it ready for collection, collecting the temporary loan or recording the outcome, with the button that takes it. Below that, the left column reads from what the repair is to what is happening: Repair context first, with its facts in two columns, then Vendor & communications and one timeline. Money sits on the right: any temporary loan, the outcome and cost, and any damage charge. The client’s name links to their person page.

In the header, the Move to menu holds every status change and Close repair. The More actions menu holds Edit details, Copy tracking link and Delete repair.

Assign

Assign or reassign a technician, or take it yourself in one click. Requires repair.update.

If your desk does not work this way, turn assignment off on the workflow page.

Change status and priority

As the work progresses. Each change is recorded in the history and, for the statuses that trigger them, sends the matching email.

Marking a submission Ready is what sends the ready-for-collection message, and the tutor notification if the student has a tutor on file.

Add notes

To the history, so colleagues have context. Notes are internal.

Issue a loan

Give the person a loaner while theirs is being repaired, or link one already issued. Plugboard can pick an available device from the right loan group automatically.

The loan and the repair stay linked, so when the repair closes you know which loaner to collect back. The loan number also appears on the person’s tracking page and in the parent portal.

Record an outcome and cost

Choose Record outcome on the repair. The same form is used everywhere an outcome is asked for, and it takes:

Field
Result	Optional. Repaired, Replaced, No fault found or Beyond repair. Choose it again to clear it
Parts replaced or repaired	From your own parts catalogue
Repair cost	Adds itself up from the parts; you can type over it
Covered by	The coverage the repair falls under
Notes

A summary line at the foot of the form says what you are about to save. The Result then shows beside Outcome & cost on the repair. Outcomes recorded before 0.16.0 have no Result until somebody edits them.

Type over the total when the job cost something else. A part sourced in a hurry, or supplied free under warranty, means the sum is wrong. What you type wins, and the parts keep the prices they were saved with, so last term’s numbers do not move when you update a supplier price.

Costs feed cost analytics.

Outcomes for several closed repairs

A repair closed without an outcome leaves billing incomplete. From 0.17.1 a standing banner at the top of the Submissions list and the dashboard says how many, such as 3 closed repairs need an outcome. It is no longer a notification that reappears on every page. The banner needs repair.view; Add outcomes on it needs repair.update and opens the same form for all of them: the repairs waiting are listed on the left and the form is on the right. Save and next records one and moves to the next, and Skip leaves one for later. On a phone you step through them without the list. The banner goes once the last outcome is in.

Send to a vendor

Raise an external or warranty repair through a configured connector, such as Apple GSX, CompNow or a help desk system. The vendor’s reference and status are tracked on the submission.

Only appears if the vendor repair workflow feature is on and a repair vendor connector is configured.

Close

When the device is returned. Closing is what invites a satisfaction rating on the tracking page.

Coverage

Each repair type carries a coverage: warranty, insurance or chargeable, or whatever you have defined.

Coverage is shown to the person when they lodge, so they know before handing the device over whether this is likely to cost them anything. It is also how cost analytics breaks spending down, which is the number your business manager asks for.

Where a family is being asked to pay, see damage charges. One person raises the charge and a second approves it.

Notifications and tracking

When a submission is lodged, the person gets a tracking link and email updates as the status changes. They can follow progress at any time on the tracking page, without an account and without asking.

This single feature removes most of the “is it ready yet” traffic from a school desk.

Automation

Routine triage can happen without you. A rule can auto-assign a cracked screen to a particular technician, set its priority, or notify a channel. See automation rules.

Realtime

The desk gets live updates. When a colleague changes a submission, lists and detail pages refresh and a toast appears, so two technicians do not both start the same job.

Permissions

Permission	Allows
repair.view	See the queue and open a submission
repair.create	Lodge one
repair.update	Change status, priority, assignment, add notes, record the outcome and cost
repair.close	Close or delete a submission

Submissions against tickets

Submissions are about a device. Tickets are about everything else. Both are independent modules and either can be switched off.