Inductions
/inductions. Needs module.inductions.
The start-of-year device handout, run in an organised way. Import a roster, work through it, record what each student was issued.
Why it is a separate feature
Section titled “Why it is a separate feature”Because handout week does not look like the rest of the year. Two hundred students, a queue down the corridor, four staff, and a spreadsheet somebody is editing while somebody else is reading from it.
Inductions exist to make that survivable, and specifically to answer “has this student already been through” without anyone shouting across a room.
Setting one up
Section titled “Setting one up”Import a roster of students who need a device, grouped into a program. A program is usually a year level or a cohort: Year 7 2026, or Staff refresh.
Rosters come from a spreadsheet, which is what schools already use for this. See the Google Sheets connector for reading one directly, or import a file.
Running one
Section titled “Running one”Track progress per student: not started, in progress, completed.
Record the device issued, and any device returned. Both are worth capturing: the returned device is how you find out what came back and what did not.
Students check their own status at the induction kiosk by tapping their card, which removes a large amount of “am I on the list” traffic from the staff running it.
The layout that works
Section titled “The layout that works”From schools that do this every January:
- One station running the induction kiosk at the front of the queue. Students tap, find out whether they are on the list and where they stand, and are sent to the right place.
- Staff stations running the inductions page, recording issued devices.
- The serial autocomplete on. Typing a serial from a sticker gets it wrong; picking it from your MDM does not.
Collecting devices back
Section titled “Collecting devices back”At the other end of the year, the same page runs the collection - end-of-year handback, without a separate screen to learn. Toggle a program to Collect returns and the roster narrows to whoever still has a device outstanding.
Scan the returned device’s serial and Plugboard matches it straight to the student it was issued to - no searching the roster by name while someone waits. A confirmation dialog then asks for two things in one step:
- Condition - Good, Fair, Damaged, or Not returned.
- Charger returned - a checkbox, ticked by default.
Both are recorded against the induction alongside who processed it and when, so “what came back, in what state, with or without its charger” is answered without asking around. There’s also a manual Mark returned action per row, for a device handed in without its sticker in reach of a scanner.
A running count - how many are back, out of how many were issued - sits above the roster, and Export outstanding downloads a CSV of everyone who has not yet returned their device: name, year level, username, and what they were issued. That is the chasing-up list, for whoever is emailing families or walking corridors on the last day of term.
Afterwards
Section titled “Afterwards”The record of who received what is the thing you will want in March, when a device turns up with no owner or a family says they never got one.
It also feeds device records, so an issued device is assigned to its student from day one rather than the first time it breaks.
Permissions
Section titled “Permissions”| Permission | Allows |
|---|---|
induction.manage |
Run inductions, import rosters, record issued devices, collect returns and export the outstanding list |
Related
Section titled “Related”- The induction kiosk, the student-facing half.
- Google Sheets for roster import.
- Devices for what happens to the record afterwards.