Follow one departure through the systems it touches
Consider an illustrative departure: an operations manager is leaving on Friday. HR has approved the effective time, IT has the access-removal request, and a successor has been named. The manager also owns a shared planning folder, open purchasing approvals, and a recurring report that a regional team needs on Monday.
Each team could complete its ticket while the report still fails or an application session remains usable. The offboarding workflow has to join these results into a case someone can inspect.
An agent can resolve records, prepare permitted actions, and reconcile the resulting state. Existing identity provisioning can continue to handle accounts it already manages, while the agent coordinates remaining applications and handovers.
Establish the departure before planning the changes
Use the authorised HR event as the starting point. Capture the employee identifier, employment relationship, effective time and time zone, approval reference, and version of the instruction. Names and email addresses help people read a case, but stable identifiers should bind its actions to the intended person.
Match that person to directory accounts and application-specific identities. Include a separately privileged account when the inventory shows one. If a display name produces two plausible matches, route the ambiguity to the owner before any access change.
HR confirms the employment event; IT owns access actions; business owners approve successors and handovers. The records owner supplies preservation requirements. An agent should not infer a recipient for confidential material from team membership alone.
Immediately before scheduled execution, recheck the authoritative event. A revised departure time or cancelled departure must invalidate the relevant queued work. Changes after access removal require an authorised recovery process that checks which actions already happened.
Give each part of offboarding its own completion test
A single checkbox obscures the different results the organisation needs. For the illustrative departure, a useful case has these separate tracks:
| Track | Required decision | Evidence of completion |
|---|---|---|
| Employment event | Approved person, time, and scope | Current HR event and approval reference |
| Access | Accounts, sessions, and grants to revoke | Target account state and results of applicable session checks |
| Business handover | Successor for files and open work | Confirmed ownership plus successor access to the required work |
| Operational dependencies | Owner and execution identity for recurring jobs | Approved reassignment and a successful controlled check |
| Records and exceptions | Preservation plan and outstanding actions | Verified preservation state; named owner for each unresolved item |
The case can report completed access removal while a records task remains open, so the next operator knows where to continue.
Check application access beyond the directory
Disabling a directory account and ending existing application access are separate checks. Microsoft explains that an application can issue its own session token, which Microsoft Entra ID cannot directly revoke. Existing access can depend on token expiry, application configuration, and synchronisation; continuous access evaluation helps where supported. Microsoft's access-revocation guidance
For each application in scope, establish the supported deprovisioning action and how to verify its effect. Check whether the application permits a direct login outside the central identity provider. Keep a pending result open until the required state is observable or an operator resolves the exception.
For Google Workspace, suspension preserves account data and blocks the user's access to services, but Google documents an exception for someone already participating in a Google Chat session: participation can continue until that session ends. Google's suspension behaviour
Treat that as a reason to test the actual session behaviour of the applications in the pilot. A successful administrative response establishes that the command was accepted; the completion record should also show the relevant target state.
Keep device recovery as a separate tracked task. The workflow must not claim to have retrieved downloaded material merely because it removed online access.
Transfer work without carrying old access forward
The successor needs enough access to continue the manager's work. Specify the files, business records, and responsibility being transferred, along with the approved recipient. Check the recipient's eligibility before changing ownership.
Google Drive illustrates why this matters. Its administrator transfer process requires an eligible recipient within the organisation, and a transfer does not by itself remove the previous owner's permissions. Google also documents hold-related restrictions on which accounts can supply files for transfer. Google's Drive ownership-transfer requirements
For the planning folder, confirm new ownership and the departed employee's resulting access. Keep unrelated sharing changes outside the approved handover.
Apply the same care to open purchasing approvals. Identify the actual pending records, nominate an authorised replacement, and verify that those records now reach the right approver. Changing a manager field in HR might leave already-created tasks assigned elsewhere.
For the recurring report, inspect both responsibility and authentication. Renaming the report owner does not prove that a scheduled job has stopped relying on the departing employee's credential. The application owner should approve the replacement identity and its permissions, then validate execution through a controlled run or another supported check.
Prepare that handover before the departure where policy allows. If a dependency remains unresolved at the approved access cutoff, escalate the service risk. Leaving the former employee's account active should not become an automatic workaround.
Preserve records before considering account deletion
Suspension, archiving, ownership transfer, and deletion have different effects. Make the preservation decision explicit for each system, including who can authorise it and what must remain retrievable.
For domain-verified Google Workspace organisations, Google warns that deleting a user ends the application of Vault retention rules and holds to that user's data; data can be purged immediately. Its documentation also says a user on litigation hold cannot be transferred or deleted through the described process. Google's user-deletion guidance
The workflow should carry the organisation's approved preservation plan through these product constraints. A blocked transfer needs review by the responsible records owner. The agent must not lift a hold to make an offboarding task succeed.
Keep licence recovery downstream of the required records checks. Record a reassigned or released licence accurately, and establish the contractual billing effect before counting it as realised savings.
Keep exceptions visible until someone resolves them
Suppose access removal succeeds and the report's new connection fails. Preserve the successful results alongside the report identity, attempted change, and application owner's next action.
Avoid restarting every step after a partial failure. Reconcile the saved action record with current application state, then continue from the unresolved operation. A duplicate event should find the existing case. A changed event should create a reviewable revision.
Use explicit states such as scheduled, confirmed complete, pending confirmation, and blocked. Each blocked item needs an accountable owner and review time. Keep credentials and unnecessary employee details out of the evidence record.
Test the handovers that are easiest to miss
Start with de-identified cases in a controlled environment, followed by a bounded deployment under the organisation's approvals. Include ordinary departures alongside changed dates, duplicate events, ambiguous accounts, and a successor who lacks the required access.
| Test case | What a satisfactory result shows |
|---|---|
| Departure cancelled before execution | Queued changes stop against the superseded event |
| Application retains an active session | The exception remains visible and reaches the application owner |
| Ownership transfer is rejected | The workflow preserves records and requests a valid resolution |
| Recurring job uses the old credential | Access removal and operational recovery have separate tracked results |
| A system cannot be inspected | The case reports unverified coverage instead of claiming completion |
Measure elapsed time from the approved cutoff to verified access outcomes, then track unresolved exceptions and broken handovers separately. Define the included systems and events so a completion rate has a meaningful denominator.
Where Monarch fits
Monarch's Product Graph maps application operations, permissions, and validation behaviour within the connected account's scope. For offboarding, evaluate the discovered and verified actions needed to join the HR event, application changes, and case evidence across the systems in your workflow.
The organisation defines the departure policy, preservation decisions, and approval boundaries. Monarch's role is to help agents carry approved work across applications and validate results. The permission-aware agent guide explains the authority checks behind those actions.
Frequently asked questions
What can AI agents do in employee offboarding?
They can reconcile employee identities, prepare approved changes, coordinate access removal and handovers, and collect completion evidence. Start with defined operations and named owners for decisions the workflow cannot resolve.
Does disabling single sign-on end every application session?
The result depends on the application. Microsoft documents that application-issued sessions require the application's own revocation behaviour. Include direct logins and active-session checks in the scoped offboarding plan.
Should offboarding delete employee accounts immediately?
Follow the organisation's preservation and account-lifecycle decisions. Confirm required records and handovers before an authorised deletion. A suspended account and a deleted account can have materially different data consequences.
Does removing a user from one organisation remove all their access?
Check the platform's membership model. GitHub documents that someone who remains in another organisation within the same enterprise can retain access to internal-visibility repositories. Local copies can also remain after online access is removed. GitHub's membership-removal effects
What should the final offboarding record contain?
Keep the approved event, resolved accounts, attempted actions, and confirmed results, together with handover evidence and unresolved exceptions. A reviewer should be able to see what happened, what remains, and who owns the next action.
Bring one departure workflow, its application inventory, and its completion criteria to a Monarch pilot discussion.