New-Employee Onboarding: A Task List That Connects HR, Equipment, Access, and Payroll

Onboarding is a dependency graph, not a flat list. It has one root - a person record with a single identifier - and one convergence point on day one, and every task in between is scheduled backwards according to its own lead time. This describes process and data flow, not obligations or entitlements.

One root: the person record

The first step is not opening an account or ordering equipment. It is creating one record that everything else points at. It is created the moment the signed offer comes back, and holds an internal identifier, the full name in one spelling, a start date, a role and a manager.

• person_id is the identifier every other system stores. Not a name, not an email address, not a national id number.
• The email address is derived from the record, never the reverse. Someone who changes their name later does not lose the link.
• The start date is the field every task schedules from. Changing it must reschedule all of them, not merely raise an alert.
• The ת"ז and bank details go to payroll and HR only, and are never copied into an IT ticket. Data minimisation is a design decision as much as a policy one.
• Microsoft Entra implements exactly this pattern and names three event types - Joiner, Mover and Leaver - with tasks scheduled relative to the value of the employeeHireDate attribute.

Why does the laptop arrive late even when the checklist was completed?

Because a checklist describes what has to happen, not when it has to start. A task with a seven-business-day lead time must open seven business days ahead, and a flat list shows it on the same line as a task that takes ten minutes. The fix is backward scheduling: every task carries a lead_time, and the system computes start_by from the start date.

The table also shows why the start date is a dangerous field. Moving it a week forward changes ten dates, and if the system only raises an alert about the change, seven of those tasks stay on the old date.

What counts as a completed onboarding task?

An artefact somebody can verify without asking anyone. The difference between "marked done" and "has an artefact" is the difference between an auditable process and a list of promises.

• Equipment order: a serial number and an asset number recorded against person_id.
• Account creation: the actual username, not the word "created".
• Access: the name of the role granted and the systems it resolves to.
• Payroll: the employee id returned by the payroll system.
• Badge: the badge number and the door groups it opens.
• Training: a completion date per module, not "started training".

Those artefacts are also what lets you answer one question on the morning of day one: what is missing. A list of ticked boxes cannot answer it. The customer-side equivalent, where the same pattern recurs with different artefacts, is described in automating customer onboarding.

Access: a defined role instead of a copy of a colleague

"Give him the same access as Dana" is the shortcut that produces the largest permissions problem in most organisations. Dana has been there four years, changed roles twice, and accumulated access she no longer needs. Copying duplicates all of it and creates a new joiner with a veteran's reach.

The correct pattern is one layer in the middle: a role. Instead of twenty direct grants there is one role mapped to a bundle of systems, and the grant is of the role. NIST SP 800-53 treats account management as its own control family covering creation, modification, periodic review and disabling. Three practical rules follow:

1. Each role is defined once and documented: which systems, at what level, and who approves an exception to it.
2. An exception is a separate grant with an expiry date, so temporary access does not quietly become permanent.
3. A first review thirty days after the start date, where the manager confirms what is actually being used and removes the rest.

The other side of the same coin is leaving. Every grant in the bundle has a matching revoke, and it should be created at the moment the grant is created rather than reconstructed later. Training on the systems the new joiner now has access to is covered in CRM and ERP training and onboarding.

Where the process actually breaks

• An offer signed two days before the start. Every lead time collapses and the process becomes a chain of phone calls.
• Payroll registered without a linked identifier, so the person exists in HR and in payroll as two separate entities.
• A role decision made on day one. IT waits, the new joiner sits with no access, and the workaround is an over-broad permission.
• Equipment that arrived but was never recorded against person_id, so at offboarding nobody knows what to collect.
• A start date changed in HR only, leaving the dependent tasks on the old date.
• A part-time or second-site joiner run through the identical template, generating tasks that do not apply.

Sources

• Microsoft Entra - What are lifecycle workflows
• NIST SP 800-53 Rev. 5 - Security and Privacy Controls