A new hire starts Monday. That fact is the input to between six and twelve independent pieces of work, spread across HR, IT, identity management, facilities, finance, and sometimes security. Each piece has its own owner, its own deadline, its own definition of "done" — and if any one of them slips, the new hire arrives to find no laptop, or no desk, or no email account, or no payroll record. GLPI's parent-child ticket structure exists exactly to model this. Here's how to set it up so a single HR submission spawns the right work in each team.
The parent ticket: one HR record, one source of truth
Create a ticket template called Employee onboarding. Mandatory fields: Employee name, Start date, Department, Manager, Role, Office location. Pre-filled: Category = HR / Onboarding, Assigned group = HR-operations. HR submits this single ticket and it becomes the parent — the user-facing thread, the one place the manager checks for status.
Don't try to make the parent ticket also do the work. The parent's only job is coordination: it stays open until every child closes. Putting actual tasks on the parent (instead of as children) breaks the cleanest property of this structure — that each child has its own owner, its own SLA, and its own independent close.
Auto-spawn the children
The Form Creator plugin can spawn multiple tickets from one form submission. Configure the onboarding form to create — based on the role and department fields — a set of children:
- Provision laptop → group: IT-hardware. Includes role-based hardware spec.
- Create AD account + provision email → group: Identity. Includes name, department, manager (for delegation).
- Add to role-based groups → group: Identity. Branched off role field.
- Assign desk + access card → group: Facilities. Includes office location.
- Payroll setup → group: HR-payroll. Includes start date and salary band.
- Order business cards + welcome kit → group: HR-operations. Includes role and location.
- Schedule onboarding sessions → group: HR-training. Includes department-specific path.
Each child is a full ticket — own SLA, own assignee, own status — linked to the parent via the Child of relationship. The manager opens the parent and sees the rollup: 5 of 7 children closed, 2 open with current owners shown.
Sequence what depends on what
Not all children are parallel. Email account creation must complete before "order business cards" can know the email address. Hardware provisioning must complete before "ship laptop to home address" can ship anything. Use the Successor of ticket link to express dependencies: Ship laptop is a Successor of Provision laptop. GLPI doesn't auto-gate on this — the second team can technically start anytime — but it documents the order so when the dependent ticket gets stuck, the dependency is visible without anyone having to remember.
Three dependencies actually matter for onboarding: hardware → image → ship; AD account → email → comms tools; ID badge → office access → desk assignment. Wire those up. The rest run in parallel.
Offboarding is the same workflow, reversed and tighter
Create a separate template — Employee offboarding — because the work and the SLAs are different. The trick with offboarding is timing: things must happen at the leave date or shortly after, never before (employee still works), never much after (security risk, especially for involuntary departures). Children:
- Disable AD account → group: Identity. SLA: end of last working day.
- Forward email + remove access → group: Identity. SLA: end of last working day.
- Collect laptop + access card → group: HR-operations. SLA: last working day.
- Wipe and re-image laptop → group: IT-hardware. SLA: 5 days after collection.
- Final payroll → group: HR-payroll. SLA: per regulation, varies.
- Update org chart → group: HR-operations. SLA: end of week.
For involuntary departures, route to a separate Offboarding (urgent) entity with restricted visibility — the existence of the offboarding shouldn't be visible to peers until it's complete. The same parent-child structure handles it; the entity boundary handles the confidentiality.
The metric that matters
"Did anyone forget anything" is hard to measure across email threads. With this structure, it's a single query: count of parent onboarding tickets where any child closed late or never closed at all. If the number is rising, your form needs more children, or your children need different owners. The point of modeling the cross-functional dance as one parent and N children is that the dance becomes auditable — and what's auditable can be improved.