Update onboarding tasks when a start date changes

What this means for your practice

Identify which tasks depend on the start date and define how changes affect them. Keep already-completed work visible so the team can decide what needs adjustment.

A practical conversation with your supplier

Move a fictional start date after several tasks are complete. Does the manager see what changed and what remains active? Agree who reviews early access and cancelled starts. The workflow should preserve the work history rather than reset every task and obscure decisions already taken.

Plan the first improvement

Map the onboarding timetable before deciding how a changed start date should work. Some tasks can move automatically; others may have already created a commitment or granted access and need a person to review them. Keep those distinctions explicit. The receiving manager should see a summary of completed, rescheduled and unresolved work instead of receiving a new set of welcome notifications with no explanation. Include a cancelled start as well as a delay in testing.

Ask who confirms which work should stop, what arrangements need reversing and what records must remain under your organisation's process. Do not assume changing one date updates every external supplier or separate application. Assign owners to those manual exceptions. After a real change, review tasks that still ran on the previous timetable and trace why. This helps improve the dependency list rather than repeatedly asking staff to remember which parts of the workflow ignore the changed date.

How to check the result

Measure tasks executed against outdated start information.