How onboarding & offboarding checklists work #
Onboarding in Edventory is built around positions, not people. You write the checklist once for "Music Teacher" or "Bus Driver", then start one every time you fill that job. Two words, two things: a checklist is the reusable list of steps; the live copy you're working through for one person is that person's onboarding (or offboarding). The Onboarding view in the sidebar's HR section holds three tabs: In progress, Completed, and Checklists.
Checklists are the templates
A checklist is a reusable list of steps for one process — onboarding or offboarding — belonging to one position. Nothing on a checklist is tied to a person or a date; steps are stored as an offset like "5 days before" or "on the first day".
An onboarding is the live copy
+ Onboard someone (or + Offboard someone) takes a snapshot of a checklist's steps, turns each offset into a real due date from the date you enter, and tracks the tick-boxes. Editing the checklist afterwards never disturbs one already under way — and working through one never changes the checklist.
Phases keep it readable
Every step sits in one of four phases — Before start day, First day, First week, First month (an offboarding checklist reads Before last day, Last day, First week after, Wrap-up). The run view groups the tasks under those headings and shows a progress bar.
ℹ️Onboarding lives alongside Staff Leave under the sidebar's HR heading. It's rolled out district by district — if you don't see it, ask us to turn it on for your district.
The base checklist and position variations #
Most of what you do for a new hire is the same regardless of the job: create the account, order the laptop, add them to the phone list. Put those steps on the base checklist, and every position checklist picks them up automatically.
Create the base first
Checklists → + New checklist, name it something like "All new staff", and tick This is the base checklist. You get one base per process — one for onboarding, one for offboarding.
Then add positions
Create a checklist per position that needs something extra — "Music Teacher", "Bus Driver", "Building Secretary". Leave the base box unticked and it inherits every base step, marked inherited in the editor.
Edit the base once, everywhere updates
Add a step to the base and it appears on every position checklist immediately — including the ones you wrote months ago. That's the point of the split: shared steps have exactly one home.
| Badge | What it means |
|---|
| inherited | Comes from the base checklist and still tracks it. Change it on the base and this position follows. |
| customized | An inherited step this position edited. It has forked — later base edits no longer reach it until you reset it. |
| added | A step that exists only on this position. |
💡No base checklist yet? A position checklist works fine on its own — it just carries all its own steps. You can create the base later and the positions you already wrote will start inheriting from it.
Customizing a position's steps #
Open a position checklist and every step is editable in place, whether it came from the base or not. Editing an inherited step doesn't touch the base — it makes this position's own copy.
Change an inherited step
Hover the step and click Edit. The dialog warns you that the change applies to this position only. Rewrite the title, move it to a different phase, shift the due offset, or point it at a different person. It now reads customized.
Undo a customization
Click Reset on a customized step to throw away the fork and go back to the base version — including any base edits made while it was forked.
Skip a step this position doesn't need
Click ✕ on an inherited step. It disappears from this position only; the base keeps it and other positions still get it. Reset brings it back.
Add position-only steps
+ Add task writes a step that belongs to this checklist alone — "issue instrument locker key", "order an audio interface".
Start from a similar position
Duplicate copies a checklist, customizations and all, under a new name. Handy when two positions differ by a step or two.
Rename it later
Job titles change. Rename retitles a checklist in place, keeping its steps, its customizations, and the positions that inherit from it. Checklists already running keep the title they started under, so a finished onboarding still says what the job was called at the time.
| Field | What to enter |
|---|
| Task | What has to happen, written as an instruction — "Create Google account", "Collect classroom keys". |
| Phase | Which stage it belongs to. Drives the grouping and the default ordering. |
| Due | Days from the start date. 0 is the start date itself, −5 is five days before, 14 is two weeks after. |
| Assignee | The team member responsible. They get an email when the checklist starts, and a nudge when the task goes overdue. Leave it unassigned to decide per hire. |
| Can't start until… | Holds this step locked until every step above it is done. See Putting steps in order. |
| Notes | Anything the assignee needs — the OU to place them in, which cart the loaner comes from. |
Putting steps in order & making one wait for another #
Some steps genuinely can't start until earlier ones land — you can't create the Google account before the hire is even approved. Order the list the way the work actually happens, then tick Can't start until the steps above it are done on the ones that have to wait.
Put the list in order
Drag a step by its ⠿ grip to move it. Drag it under a different phase heading and it moves to that phase. No mouse? Tab to the grip and use ↑ / ↓ — same result, and your place in the list is kept.
Mark what has to wait
Edit a step and tick the box. It now shows ⛓ waits on the checklist, and on a live run it stays locked — greyed out, with its tick-box disabled — until every step above it is done or skipped. It says how many it's still waiting on.
Let the rest run in parallel
Leave the box unticked on anything that can happen any time — ordering the laptop, the badge photo. Only the steps you gate wait, so a checklist doesn't turn into a single-file queue.
The handoff
The moment the last step above it is ticked off, the gated step unlocks and its assignee is emailed that it's their turn. Whoever ticked the box sees who's up next.
💡Worked example. Order the steps Interview → Hire approved → Payroll paperwork → Create Google account, and gate only the last one. IT hears nothing while HR works through the first three; the day paperwork clears, the account request lands in their inbox.
ℹ️Reordering a step on a position checklist changes the order for that position only, so that step becomes customized — the steps around it keep tracking the base. Reorder on the base checklist and every position follows.
Onboarding or offboarding someone #
Click + Onboard someone or + Offboard someone, pick the position's checklist, name the person, and set the date. Edventory copies the resolved steps — base plus this position's variations — and turns every offset into a real due date.
Pick who it's for — or don't, yet
Type a name, or search your roster to link it to a real person. Linking matters for offboarding (see below) and fills the name in for you. The field is optional: start the paperwork for a post you haven't filled and it simply reads "no name yet" until you know. Edit details on the record puts the name in whenever the offer is accepted.
Set the date
The Start date (or Last day, offboarding) anchors every due date. Change it later under Edit details and every still-open task shifts by the same number of days — which is what you want when a start date slips.
See who owns what
Every step carries its assignee's name in their own colour, and the chips above the list show each person with how many steps they still have open. Click one to narrow the list to just that person's work.
Work the list
Tick tasks off as they're done; the progress bar and the In progress row update. Tick the last one and the run moves to Completed and emails everyone who worked on it. Un-tick a task on a finished run and it comes back to In progress.
Adjust it as you go
It's a copy, so you can edit it freely: Edit details for the name, date or notes, + Add task for the one-off that came up, Edit on a step to reassign or move a due date, ✕ to drop one that doesn't apply to this hire. None of it touches the checklist.
ℹ️Each one keeps the position name it started under. Rename or delete the checklist afterwards and anything already in flight is unaffected — so a finished onboarding still records what the job was called at the time.
Offboarding: collecting devices, loaners, and seats #
The gear a departing employee is holding is already in Edventory, so an offboarding run doesn't make you look it up. Link the run to a person from your roster and Edventory adds a collection task for every device assigned to them, every loaner they still have out, and every license seat in their name.
Preview before you start
Choose an offboarding checklist and pick the person, and the dialog lists exactly what will be added — "3 collection tasks will be added from what they currently hold: CB-0421, HP-1180 (loan), Adobe Creative Cloud (seat)". Nothing assigned? It says so.
The tasks arrive tagged
Collection tasks appear in the run marked from inventory, alongside the checklist's own steps. They're normal tasks from there — assign them, re-date them, or delete one that doesn't apply.
Ticking them off isn't a check-in
Marking a collection task done records that the item came back on the checklist. Actually returning the loaner or reassigning the device still happens on the device record or in the loaner pool, so your inventory stays the single source of truth.
💡License seats are matched on the person's email address, so keep roster emails accurate — that's how a seat gets tied back to the human who's leaving.
Who gets emailed, and when #
Onboarding usually spans several people — IT builds the account, the office does payroll paperwork, a building admin hands over keys. Edventory emails each of them their own slice rather than copying everyone on everything.
| When | Who hears about it |
|---|
| A checklist starts | Every assignee gets one digest listing only their tasks, with due dates. Nobody gets a message for the tasks you kept for yourself. |
| A task is assigned later | Just that person, with the task and its due date. Assigning something to yourself sends nothing. |
| A gated step unlocks | Its assignee, the moment the last step above it is done — "it's your turn". This is the handoff, so they aren't told about it on day one when they couldn't act anyway. |
| A task goes overdue | One nudge per assignee per day, listing everything of theirs that's past due across all their runs. Ticking it off in time means no email at all — and a step that's still waiting on earlier ones is never nagged about. |
| The run finishes | Everyone who was assigned a task on it, plus whoever started it. |
Need to chase people mid-run? ✉ Re-send assignments on the run re-sends each assignee their open tasks, and tells you how many people it reached.
Several steps in a row go out as one email
Checklists usually hand work over in stretches: the office does the paperwork, then IT does four things in a row, then the principal signs off. When the first of those four unlocks, IT gets one email listing all four — not one email now and another every time they finish a step. They can see the whole handoff, start at the top, and work down without their inbox filling up behind them.
A stretch ends as soon as a step belongs to someone else. If IT owns two steps, then the principal owns one, then IT owns another, that's two separate handoffs to IT, and they hear about each one when it comes round.
Turning email off for a single step
Some steps are their own notification — you're standing next to the new hire while they sign the handbook. Untick Email the assignee about this step when you add or edit it, and that step goes quiet: no start digest entry, no "assigned to you", no "your turn", no overdue nudge. Steps set this way show a small no email tag in the checklist.
It only affects email. The step still appears in the checklist, still has to be ticked off, still keeps its place in the order, and still holds back any step gated behind it.
ℹ️Turning email off for one step never silences the steps after it. If a quiet step is the first in someone's stretch, the next step of theirs that does send email becomes the one that announces the handoff.
ℹ️Reminders only go to team members with an Edventory login. A step assigned to nobody never emails anyone — it still shows in the run as unassigned so it doesn't get lost.
Who can see and edit checklists #
Onboarding is a permission like any other feature area, with a second level for the people who own the process. Grant them under Team → a member → Permissions.
- Onboarding — see the runs and checklists, tick tasks off, and add or edit tasks on a live run. This is what most of the team needs: they're doing the work, not designing the process.
- ⚙ Edit checklists — additionally create, edit, duplicate, and delete the checklists themselves. Reserve it for whoever owns onboarding, so a well-meaning edit to the base doesn't reshape every position at once.
Administrators have both. Nobody without the Onboarding permission sees the sidebar entry at all.
ℹ️Deleting the base checklist is refused while position checklists still inherit from it — unlink or delete those first, so no position is left pointing at a checklist that's gone.