Staff onboarding.
A new teacher's first days should never be improvised. YESS gives every new hire a checklist — spawned the moment they are added, drawn from a template that matches their staff type, and worked task by task until it is done. Documents collected, IT set up, orientation given, the handbook read, role training booked: nothing forgotten, and a glance shows how far along each joiner is. This handbook walks the checklist honestly — what it tracks, how it is created, and the line between reminding you to provision an account and provisioning it for you.
- 5task categories
- 3checklist states
- autospawned on hire
- ≈8 minto read
Prologue
From signed contract to first class#
The gap between "we've hired her" and "she taught her first lesson" is where good onboarding lives — and where most schools drop things. The contract is signed but the ID never gets copied; the email account is promised but not created; orientation happens in a corridor conversation nobody remembers. Staff onboarding in YESS closes that gap with a checklist that starts itself and is worked to completion.
One clarification up front, because the word is overloaded. This book is about staff onboarding — the HR new-hire checklist at /dashboard/onboarding. It is not the same thing as the school's own signup wizard (the tenant onboarding that stands a new school up on the platform). Different feature, different place; this one is about the people you hire.
A first day that runs on a list, not on memory.
Chapter one
The checklist template#
Onboarding starts from a template — a named, reusable checklist a school builds once and applies to every hire of a given kind. Templates are created from /dashboard/onboarding and carry a name, a description, a staff type, and a list of tasks.
Staff type
A template is scoped to a staff type — teaching, non-teaching, administrative, support, or all — so a teacher and a bursar can get different first-week lists. When a hire needs a checklist, the platform picks the active template whose staff type matches, and falls back to an all template if there is no exact match.
Five task categories
Each task on a template carries a title and one of five categories, so a checklist reads as a coherent first week rather than a flat to-do list:
- Documents — ID, qualifications, references, signed paperwork.
- IT setup — email account, system access, devices.
- Orientation — the campus tour, the introductions, the lay of the land.
- Training — role-specific and platform training.
- Compliance — the handbook, the policies, the safeguarding sign-offs.
Each task is also marked required or optional — a distinction that matters when the checklist decides it is finished (Chapter three).
Chapter two
A checklist for every hire#
A template is the pattern; a checklist instance is the one that belongs to a specific new hire. YESS creates instances two ways.
Two ways a checklist begins
- 1
Automatically, on hire
The moment a staff record is added — whether created directly or promoted from a recruitment application marked 'hired' — a database trigger spawns an onboarding checklist for that person. It copies the matching template's tasks, or, if the school has no matching template yet, falls back to a built-in default checklist so a hire is never left without one.
- 2
Manually, on demand
From the onboarding screen, HR can also start a checklist by hand: pick the staff member, pick the template, and the instance is created with every task reset to not-done. Useful for a re-onboarding, a role change, or a hire that predates the template.
The auto-spawn is idempotent — a person only ever gets one checklist, even though a recruitment hire touches the staff record and the application in quick succession. The built-in fallback covers the essentials every school shares: sign the contract, collect ID and qualifications, provision email and system access, the campus orientation, read the handbook, and role-specific training.
Chapter three
Working the checklist to done#
Each checklist instance is a card on the onboarding screen, grouped into in-progress and completed. Expanding a card shows every task with its category; ticking a task stamps it complete with the time and the person who ticked it, and the card's progress bar fills.
The checklist finishes cleverly: an instance flips to completed once every required task is done — optional tasks left open do not hold it back. An instance moves through just three states: in progress, completed, or cancelled. The screen's headline tiles roll the instances up into the numbers HR actually watches — how many onboardings are active, how many are complete, how many templates exist, and the average completion across everyone in flight.
Chapter four
What the checklist tracks, and what it does not#
It is worth being exact about what onboarding is. It is a tracking tool — a reliable, auto-starting record that the right steps happened — not an executionengine that performs them for you.
Concretely: the "provision email and system access" task is a checkbox you tick once you have created the account — onboarding does not itself create a login, assign a role, or hand over credentials. Account creation and role assignment happen in the platform's user and roles area; the checklist is where you record that they were done. Reading onboarding as "the list that makes sure nothing is forgotten" is exactly right; reading it as "the robot that sets up the new hire's account" overstates what is built today.
Chapter five
What makes onboarding careful#
Four things done properly
- 1
It starts itself
A checklist is spawned the instant a hire is added, by a database trigger — no one has to remember to create one, and the idempotent guard means a person never gets two. A hire is never left with a blank first week.
- 2
A built-in safety net
Even a school that has built no template gets a sensible default checklist — contract, documents, IT access, orientation, handbook, training — so onboarding works on day one, not after setup.
- 3
Finishes on what matters
The instance completes when the required tasks are done, so optional polish never blocks a joiner from being counted ready — and the completion numbers stay honest.
- 4
Typed to the person
Teaching and non-teaching hires can get different lists through staff-typed templates, with an 'all' fallback that guarantees every hire matches something.
Planned & honest gaps
What is still to come#
The onboarding loop — template, auto or manual instance, task completion, KPIs — is genuinely wired end to end. What is scaffolded but not finished sits around the edges, and is named here plainly.
Four honest gaps
- 1
Real provisioning
The 'provision account' task is a checkbox, not an action — onboarding does not yet create the login, assign the role, or send the credentials. Turning the IT-setup task into a real one-click provision is the headline planned work.
- 2
Ownership of the checklist
A checklist can be assigned to a specific HR officer in the data model, but nothing sets that owner today — everyone with HR access sees every checklist. An assignee and a 'my onboardings' view are planned.
- 3
Template editing
Templates can be created, but the screen does not yet offer edit or delete of an existing template — refinement means creating a new one. Full template management is planned.
- 4
A working notification link
The 'onboarding ready' notification sent on a recruitment hire currently deep-links to a route that no longer exists, so the tap does not land on the checklist. Fixing the deep-link (and notifying on direct hires too) is planned.
Adjacent modules
Where onboarding connects#
Onboarding is the entry ramp of the employment relationship. It is triggered by hiring, records the account the platform provisions, and mirrors the exit that offboarding handles.
Adjacent modules
- 18HR & recruitmentA checklist is spawned when a hire is added or a recruitment application is marked hired; onboarding is one chapter of the wider HR module.
- 51Staff offboardingThe mirror image — the clean exit that revokes access and settles final pay when someone leaves.
- 27Platform foundationThe actual account creation and role assignment an IT-setup task tracks happen in the platform's users and roles area.
- 19Payroll & taxA signed contract and a provisioned account are the prerequisites for a new hire landing on the first payroll run.
- 17NotificationsThe 'onboarding ready' signal to HR rides the notifications fabric when a recruitment hire completes.
Tutorial
Do it step by step#
Set up onboarding once, then watch it run itself for the next hire. Four steps, in the order a school actually onboards.
- 1
Build a template
On /dashboard/onboarding, create a checklist template — name it, choose a staff type (or all), and add the tasks a new hire must complete, each tagged documents, IT setup, orientation, training, or compliance, and marked required or optional.Type one template 'all' as a universal fallback so every hire matches something even before you build role-specific lists.
- 2
Let it start itself
Add the new hire (or mark their recruitment application hired) and a checklist appears for them automatically, drawn from the matching template — or a built-in default if you have none. You can also start one by hand from the onboarding screen. - 3
Work it to done
Open the hire's card and tick each task as it is completed — each tick stamps who did it and when. The card completes once every required task is done; optional ones left open do not hold it back. Your headline tiles track active, completed, and average completion. - 4
Provision for real, then record it
For the IT-setup task, create the account and assign the role in the platform's users and roles area, then tick the task to record it. Onboarding tracks that provisioning happened — it does not perform it — so verify the account exists before you mark it done.
A first week that starts on its own, tracks to done, and never forgets the paperwork — so the teacher can think about the teaching.