A new hire no show exposes a flaw that normal onboarding checklists hide. Accounts may be active, orientation meetings scheduled, equipment in transit, payroll records pending, and company-brain reading assigned to someone who will not start. A delayed start or withdrawn offer creates the same risk. If each team only closes its own ticket, unsafe access and misleading task status can survive for days.
Use an onboarding rollback instead of asking everyone to “undo their part.” This guide gives People Operations and system owners a state model, compensating actions, failure rules, and a negative-verification checklist that proves the pre-start footprint is gone or safely paused.
Why onboarding automation is hard to reverse
Most onboarding automation is designed as a one-way sequence:
- Recruiting marks a candidate hired.
- The HR system creates a worker record.
- Identity automation creates accounts and groups.
- IT assigns equipment and applications.
- Calendars, training, payroll, benefits, and knowledge tasks appear.
- The company brain tells the employee what to do next.
The workflow usually assumes that the hire will start. A late change breaks that assumption after several systems have already accepted the original event. Replacing start_date in the HR system may move a welcome email, but it does not prove that a temporary password expired, a shipping label was intercepted, a payroll record was paused, or a confidential onboarding page became inaccessible.
The failure is distributed ownership. Each system can report success for the operation it performed while the overall outcome is wrong. The identity provider knows that an account exists, not whether the employment decision still applies. The calendar knows that an event is scheduled, not whether the invitee should attend. The company brain knows that reading was assigned, not whether the reader still has a valid relationship with the company.
Microsoft's lifecycle workflows documentation shows why the source event matters: joiner and leaver tasks are driven by employee attributes and lifecycle timing. Your design needs the same discipline for pre-employment exceptions. A changed employment state must trigger a new workflow, not merely edit the data that triggered the old one.
Define the states before handling a new hire no show
Do not use one Boolean field called onboarding_active. It cannot distinguish a delay from a withdrawal, and those states need different actions. Use a small authoritative state model:
planned: the offer is accepted, but no side effects are allowed yet.approved_for_preboarding: named pre-start actions may run.delayed: the person may still join, so reversible resources are suspended or re-dated.withdrawn: the employment relationship will not start, so resources must be revoked and records handled under policy.no_show_pending: the expected start passed, but an accountable HR owner has not confirmed the outcome.no_show_confirmed: HR confirmed that the person did not start and rollback may complete.started: an authoritative employment event confirms the worker began.
Only the HR or recruiting system that owns the employment decision may move a person into withdrawn, no_show_confirmed, or started. A manager's chat message can open an urgent case, but it should not become the authoritative event. That rule prevents an automation mistake from deleting access for a legitimate employee.
Attach a monotonically increasing version to every state change. Consumers should reject an older event that arrives after a newer one. A delayed message saying approved_for_preboarding must not recreate an account after withdrawn has already been processed.
Inventory side effects instead of relying on memory
Rollback starts with a ledger of what onboarding created. Every forward action should write an entry containing:
- the employee onboarding identifier
- the lifecycle event version that authorized the action
- the target system and resource identifier
- the action, timestamp, and result
- the accountable owner
- the compensating action
- whether compensation is automatic, manual, or impossible
- the current rollback result and evidence reference
The SCIM protocol in RFC 7644 standardizes identity-resource creation, modification, and deletion, including error and bulk-operation handling. SCIM can carry some compensating operations, but it is not the whole ledger. Equipment shipments, payroll cases, calendar events, knowledge assignments, and building access sit outside that protocol.
The ledger is operational evidence. The identity provider remains authoritative for account state, and the carrier remains authoritative for shipment state. The ledger records what to inspect and where to find proof.
A minimal handler can follow this pattern:
on_lifecycle_change(person, event):
require event.version > person.last_processed_version
freeze_new_onboarding_actions(person)
if event.state == "delayed":
suspend_access(person)
redate_reversible_tasks(person, event.new_start_date)
route_nonreversible_items_to_owners(person)
elif event.state in ["withdrawn", "no_show_confirmed"]:
suspend_access(person)
compensate_all_recorded_side_effects(person)
verify_no_active_footprint(person)
elif event.state == "started":
require_hr_start_confirmation(person)
resume_approved_actions(person)
record_results_and_exceptions(person, event.version)Make every operation idempotent. Receiving the same withdrawn event twice must not create duplicate tickets, delete unrelated records, or send another sensitive notification.
Freeze first, then compensate safely
The first rollback action should stop new side effects. Pause the person's onboarding orchestration, outbound messages, role assignments, and company-brain task generation. Without a freeze, one integration may recreate a resource while another team is removing it.
Next, suspend privileged access before attempting destructive cleanup. Suspension is fast, reversible, and easier to verify across uncertain states. Deletion can follow after HR confirms the final outcome and retention rules are applied. This ordering follows the access logic in NIST SP 800-207: access decisions should use current identity, resource, and policy context rather than trust inherited from an earlier approval.
Use a compensating action for each system:
Identity and applications
Disable sign-in, revoke active sessions, remove pre-start groups, invalidate one-time credentials, and cancel pending application invitations. Check both the main identity provider and applications that allow direct accounts. A successful directory suspension does not prove that every software account follows it.
Company brain and onboarding knowledge
Remove employee-specific assignments, revoke preboarding links, stop reminders, and clear cached permission projections. Keep stable policy pages intact. The Kipwise employee onboarding workflow provides product context for assigned reading, searchable knowledge, and progress tracking. Rollback should reconcile those employee-visible tasks without deleting shared company knowledge.
Calendar and communications
Cancel employee-facing meetings, remove the person from private channels, stop automated welcome messages, and notify internal attendees with a minimal explanation. Do not put a withdrawn offer or no-show reason in broad calendar descriptions or chat channels.
Equipment and physical access
Ask the logistics owner to intercept an unshipped or in-transit package. If interception fails, create a custody exception with a named owner and deadline. Cancel badge production where possible, revoke building authorization, and verify that temporary visitor credentials are inactive. Never mark equipment rollback complete only because an email was sent to the carrier.
Payroll, benefits, and HR tasks
Pause pending records and route them to the owners of those systems. Do not erase evidence blindly. Employment, tax, recruiting, and security records may have separate retention requirements. The rollback engine should change operational state and record the exception; the accountable record owner decides deletion under policy.
Human assignments
Cancel buddy introductions, manager check-ins, orientation sessions, and support cases that reveal unnecessary employee details. Tell internal owners only what they need to know: the start is delayed, or onboarding has stopped. Keep sensitive recruiting context in its source system.
Maintained practitioner processes already assign pre-start work to named owners. The GitLab onboarding handbook includes pre-start issues, access requests, hardware tasks, notifications, and support paths. That structure makes rollback possible because the organization can identify who owns each unfinished or reversible action.
Handle delayed starts differently from withdrawn hires
A delayed start needs a controlled pause rather than a full withdrawal.
Suspend access that is not required during the delay. Re-date tasks from the new authoritative start date. Reconfirm the manager, role, location, equipment destination, and policy scope before resuming. If a resource cannot be paused safely, remove it and recreate it later from the current approved state.
Set an expiry on the delay. If HR does not confirm a new date by that deadline, move the case to manual review. Do not let an account remain suspended indefinitely while licenses, group membership, or shipment custody go unchecked.
For a withdrawn hire, stop future work and complete the full compensating sequence. For a suspected no-show, freeze access immediately but wait for authoritative confirmation before destructive actions. This balances security with the risk of acting on a scheduling or communication error.
Design for partial rollback and unreachable systems
Rollback will fail in pieces. A carrier may reject an interception. An application may be down. A direct account may not support automated suspension. A calendar event may have been copied outside the managed tenant.
Do not hide these results behind rollback_complete: false. Record each exception with the resource, owner, next action, deadline, and safe interim control. The overall case stays open until every item is either verified complete or accepted as a documented exception by an accountable owner.
Use these decision rules:
- If access cannot be revoked, block it upstream and open a critical owner task.
- If an item cannot be recovered, classify the custody risk and start the approved response process.
- If an external system is unavailable, keep retry counts bounded and require manual confirmation after the deadline.
- If the ledger lacks a resource identifier, search only the relevant authoritative system and record how the match was made.
- If state conflicts exist, keep the safer suspended state until HR resolves the employment decision.
- If compensation could destroy a required record, restrict access and defer deletion to the record owner.
The company brain should never tell the former prospective employee that rollback is complete. It should stop answering through that identity. Internal owners may query a restricted status view that lists safe state, unresolved exceptions, and deadlines without exposing recruiting notes.
Prove that the onboarding footprint is gone
Negative verification must search for state that should no longer exist. Completed rollback tasks alone do not prove that the state is gone.
For a confirmed withdrawal or no-show, verify:
- sign-in is blocked and active sessions are revoked
- pre-start groups and direct application accounts are inactive
- company-brain assignments and employee-specific links no longer resolve
- welcome messages, reminders, and future employee meetings are canceled
- badges and building permissions are inactive
- shipments are intercepted, returned, recovered, or tracked as owned exceptions
- payroll, benefits, and training work is paused or closed by the authoritative owner
- buddies, managers, and internal support owners received a minimal status update
- no delayed integration event recreated a resource after rollback
- every exception has an owner and deadline
Run the checks from authoritative systems, not from the orchestration ledger alone. Then replay the original hire event with its old version and confirm that consumers reject it. This catches the dangerous case where rollback succeeds once but a late message rebuilds the footprint.
Test at least four scenarios before launch: a delayed start that later resumes, an offer withdrawal before access creation, a no-show after accounts and equipment exist, and a partial rollback while one system is unavailable. The expected result should name both the final state and the remaining evidence.
Put one rollback path into production
Start with one population, such as remote employees who receive pre-start knowledge and a laptop. List every forward action that occurs between offer acceptance and confirmed start. Add its compensating action, owner, deadline, and verification query to the ledger. Then simulate a no-show after the last pre-start action has run.
Do not launch until the test proves two outcomes: the person cannot use any pre-start access, and every item that cannot be reversed automatically appears as an owned exception. The next action is to take one recent onboarding record and trace its identity, knowledge, calendar, equipment, physical-access, and HR side effects. Any action without a compensating step or verification query is the first control to fix.
References
- Microsoft Entra lifecycle workflows supports event-driven joiner and leaver tasks based on employee attributes and lifecycle timing.
- IETF RFC 7644: SCIM Protocol supports standardized identity-resource creation, modification, deletion, bulk operations, and error handling.
- NIST SP 800-207: Zero Trust Architecture supports access decisions based on current identity, resource, and policy context.
- GitLab onboarding handbook supports explicit pre-start tasks, access and hardware requests, owners, notifications, and support paths.
- Kipwise employee onboarding supports the product context for assigned reading, searchable company knowledge, and onboarding progress.
