Human Oversight
Part of Employee process automation
Escalating an incomplete employee offboarding action
Escalate an unfinished offboarding task with the affected resource, observed state, action owner and evidence needed to close it.
When an offboarding action remains incomplete, escalate the specific resource and its access risk immediately to an owner who can act. Keep the original task open until the intended outcome is verified. A reminder to a general queue is insufficient when an account may still be usable.
Identify what failed
First establish the person, resource, intended action and effective time. Check whether the task was never assigned, was assigned but not attempted, failed in a system, or was actioned without confirmation. These states call for different responses.
An unreturned laptop is an asset issue; an active account after access should end is an access issue. Both can appear in the same case, but one should not hide the other.
Gather only the details the responder needs: the employee’s unique identifier, affected system, current status, last known attempt, error or blocker, and a safe contact route. Avoid copying a full personnel file into an escalation message.
Offboarding Task Status Overview
- Unassigned tasks
- Check workflow history in Microsoft Entra ID Governance
- Tasks not attempted
- Verify via lifecycle workflow extensibility logs
- Failed system actions
- Review error codes and integration logs
- Actioned without confirmation
- Validate against audit trails in identity governance tools
Route by urgency and authority
Send an unresolved access removal to the team able to suspend or otherwise contain that access, with the security or process owner included according to the organisation’s procedure. If the ordinary operator cannot act, the escalation should identify the authorised backup or incident route. An equipment return delay goes to the asset owner, while any related access or data concern follows its own route.
Do not mark the action complete because another control was applied. If a central sign-in was disabled but a separately managed application still shows an active account, record both states and keep the application action open. If an emergency measure is used, record who authorised it, what changed and what still needs to be checked.
A useful escalation record has five parts:
- Expected state:what should have happened and when.
- Observed state:what the relevant system or owner currently confirms.
- Immediate action:who is containing the issue and the next check time.
- Decision owner:who can approve an exception or further action.
- Resolution evidence:the source and time of final verification.
Close the loop
The responder should update the task with the action taken and its result. The case owner then checks the target system or receives confirmation from its accountable owner. If the first attempt fails, retain the failure and subsequent attempts in order; replacing the original status with a later green tick obscures the delay.
Review repeated escalations for a common cause, such as missing application ownership, late notice from HR or an automation that reports dispatch as completion. Change the process only after identifying which handoff failed.
Where the organisation's own policy calls for timely removal or suspension of access when it is no longer needed, use that principle to set a clear internal response target appropriate to the risk, without assuming every organisation has the same procedure.
