To automate Microsoft 365 offboarding, you build leaver workflows in Microsoft Entra ID Lifecycle Workflows that fire off a date attribute on the user object rather than off a ticket somebody has to remember to raise. You set employeeLeaveDateTime on the account, and Entra runs a pre-offboarding workflow before the last day, an offboarding workflow on the day itself, and a post-offboarding workflow after it, each carrying built-in tasks such as Disable User Account, Remove user from all groups, Remove all licenses for user and Delete User Account. The trigger is a date, the scope is a rule, and the run leaves a history you can show an auditor. This guide walks the whole build, states the licence it needs honestly, and covers the four things it will not do for you.
The leaver who kept a licence for four months
Start with the failure this is meant to fix, because it is almost never a technical failure. Someone leaves. The service desk blocks sign-in on their last day, gets pulled onto something urgent, and the rest of the sequence never happens. Four months later the account is still enabled in three security groups, still holding a full seat, and still counted on the invoice.
The arithmetic is worth doing with your own numbers rather than anybody's benchmark. A 250-user organisation with typical churn might lose 30 people a year. If each offboard is completed on average six weeks late, that is roughly 3.5 seat-months of waste per leaver, so about 105 seat-months a year. At £22 a seat that is a shade over £2,300; at £35 it is nearer £3,700. Change any input and the answer moves, which is the point: your finance lead can check that sum in their head.
The cost is the part that gets a budget conversation. The risk is the part that gets a board conversation. A leaver with live group memberships still has whatever those groups grant, and at 50 to 600 users the same person usually holds shared credentials, a Teams membership with customer data in it, and a mailbox nobody has read since they left. Automation matters here not because the manual steps are hard, but because a manual process that runs 30 times a year will be skipped at least once, and you will not know which once.
What the admin centre delete actually covers
The manual baseline is worth being precise about. In the Microsoft 365 admin centre, Users then Active users, selecting a person and choosing Delete user runs a bundle: it can remove the licences, give someone access to the OneDrive and the email, and then delete the account. It is a genuinely useful flow for a single leaver and you should not be embarrassed to use it.
What it is not is a process. It does nothing until a human opens it, it treats every leaver identically regardless of role or department, it produces no record beyond the audit log that anyone would recognise as evidence, and it cannot run a week before the last day or thirty days after it. Getting the order of operations right also matters more than people expect, because removing a licence before you have dealt with the mailbox loses data. The Microsoft 365 offboarding checklist sets out that sequence step by step, and it remains the right reference for what good looks like. This article is about making that sequence run on its own.
The licence question, answered before you plan anything
Be clear on this before you design a thing, because it decides whether the rest of the article is relevant to you.
Lifecycle Workflows requires Microsoft Entra ID Governance or Microsoft Entra Suite licences. It is not in Microsoft Entra ID P1, it is not in Microsoft Entra ID P2, and it is therefore not in Microsoft 365 E3 or E5 by virtue of the Entra plan they include. Microsoft Entra ID Governance is a separate subscription that sits on top of a qualifying plan, and Microsoft has been explicit that no new identity governance capabilities will be added to the Entra ID P2 SKU.
You also need enough licences to cover every member user in scope of the workflow, plus whoever configures it, rather than a single administrator seat. Microsoft's own worked example is a pre-offboarding workflow scoped to 50 users, which needs 51 licences. For a 300-user organisation offboarding 30 people a year, that changes the shape of the business case: you are not licensing 30 leavers, you are licensing whatever population the workflow's scope covers.
There is a trial. A Global Administrator in a commercial tenant that already holds a qualifying product such as Microsoft Entra ID P1, and has not trialled it before, can start one from the Microsoft 365 admin centre under Billing then Purchase services, searching for Microsoft Entra ID Governance and selecting Details then Start free trial. That is the honest way to test the workflows below against your own tenant before anyone signs anything.
Build the leaver workflow
Creating a workflow in the Microsoft Entra admin centre always starts from a template, and there are 14 built in. Four matter for leavers, and the reason there are four is that offboarding is not one moment.
Pre-Offboarding of an employee runs by default seven days before employeeLeaveDateTime, carrying Remove user from selected groups and Remove user from selected Teams. This is the one people skip and then regret: it is where you pull someone out of the payroll group and the finance Team while they are still around to hand over.
Offboard an employee runs on the leave date itself, with Disable User Account, Remove user from all groups and Remove user from all Teams. This is the workflow that closes the door.
Post-Offboarding of an employee runs after the leave date, with Remove all licenses for user, Remove user from all Teams and Delete User Account. This is the workflow that stops the seat billing, and the offset you choose here is the single most expensive number in the whole design.
Real-time employee termination has no execution condition at all. It is on-demand only, carrying Remove user from all groups, Delete User Account and Remove user from all Teams, and it exists for the walk-out-today case.
The wider task catalogue is where you tune each one. Alongside the tasks above it includes Revoke all refresh tokens for user, Remove all access package assignments for user, Send email to manager before user's last day, Send email on user's last day and Send email to user's manager after their last day. Session revocation being a built-in task is worth noting, because plenty of offboarding guides still present it as something you have to script.
Two more templates deserve a mention even though they are not strictly leaver-driven: Pre-Offboard inactive users and Offboard inactive users trigger on sign-in inactivity rather than a leave date, defaulting to 90 and 120 days respectively. They are the automated cousin of the report in our guide to finding inactive Microsoft 365 users, and they catch the accounts that never had a leave date because nobody ever told anyone the person had gone.
Scheduling, scope, and the attribute the whole thing hangs on
Three configuration details decide whether this works in practice.
The attribute is not free. employeeLeaveDateTime is not populated for you. It comes from HR-driven provisioning, from Microsoft Entra Connect, or from a script writing it through Microsoft Graph. Writing it in a delegated context needs the Global Administrator role along with the User.Read.All and User-LifeCycleInfo.ReadWrite.All permissions, which is a higher bar than most reporting tasks and worth raising with whoever owns your HR integration early. If nobody sets the date, nothing runs, and the workflow will look broken when it is simply idle.
Scheduling is opt-in. New workflows are enabled by default, but scheduling is not, so a workflow can sit there looking correct and never fire. Once scheduled, workflows are evaluated on a tenant-wide interval that defaults to every three hours and can be set anywhere from 1 to 24 hours, under ID Governance then Lifecycle workflows then Workflow settings in the Microsoft Entra admin centre. You need at least the Lifecycle Workflows Administrator role to change it.
On-demand runs ignore your execution conditions. Running a workflow on demand applies its tasks to the user whether or not they meet the scope and trigger. That is exactly what you want for a same-day termination and exactly what you do not want when you are testing, so test against an account you are willing to lose.
One piece of good news on timing: if the leave date is set late, say because the HR system was updated after the fact, Lifecycle Workflows will still attempt to process the user provided the setup is completed within three days of the intended processing time. That catch-up behaviour does not apply to the Time based attribute V2 option currently in public preview.
Five moves. Entra automates one, two, three and five. The fourth is the one that decides whether anybody trusts the other four.
The four things it will not do
Lifecycle Workflows governs the identity. Microsoft 365 offboarding is broader than the identity, and these four gaps stay yours.
The mailbox. There is no task to convert a user mailbox to a shared mailbox, and the ordering trap is real: the mailbox must still be licensed at the moment you convert it, so this has to happen before the post-offboarding workflow strips the licence, not after.
The files. Handing a manager access to the leaver's OneDrive is a SharePoint admin centre job. Nothing in the leaver templates touches it.
The device. Retire and wipe live in the Microsoft Intune admin centre, and no lifecycle task reaches them. Scheduled Intune reports are the practical way to prove which leaver devices actually checked in and complied.
The invoice. Remove all licenses for user frees the assignment. It does not reduce a prepaid subscription quantity, so the saving reaches your bill only when someone acts at renewal. If the licence came from group-based licensing, the group membership is what holds the seat, which is why the group tasks and the licence task belong in the same workflow.
Here is the script for the first gap, sized to be run once per leaver in the window between the last day and the post-offboarding run.
# Fills the gaps Lifecycle Workflows does not cover, before the licence is removed
Connect-ExchangeOnline
Connect-MgGraph -Scopes "User.RevokeSessions.All"
$Leaver = "leaver@contoso.com"
$Manager = "manager@contoso.com"
# Belt and braces: end every active session now rather than waiting for token expiry
Revoke-MgUserSignInSession -UserId $Leaver
# Convert while the mailbox is still licensed, or the conversion is not available
Set-Mailbox -Identity $Leaver -Type Shared
Add-MailboxPermission -Identity $Leaver -User $Manager -AccessRights FullAccess -InheritanceType All
Add-RecipientPermission -Identity $Leaver -Trustee $Manager -AccessRights SendAs -Confirm:$false
Write-Host "$Leaver converted to shared and delegated to $Manager"
Read it before you run it. Revoke-MgUserSignInSession is redundant if your offboarding workflow already carries the revoke task, and harmless if it does. The conversion keeps email and calendar reachable at up to 50 GB without a paid seat, which is what makes it safe to let the workflow take the licence off a day later. Do not delete the account while the shared mailbox is in use, because the account anchors it.
If that sequence looks like something you would rather see running continuously than remember per leaver, a 14-day EtherInsights trial shows the same checks against your own tenant.
The honest limit of automating this
Lifecycle Workflows is good. It is also a mechanism, not an outcome, and three things separate the two.
Somebody has to own it. A workflow with no owner drifts: the scope rule stops matching a department that got renamed, a template gets edited during a busy week, and nobody notices until an offboard silently does nothing. Workflow history gives you the raw material, viewable by users, runs and tasks, but raw material is not a review.
Somebody has to produce the evidence. Your auditor, your Cyber Essentials assessor and your largest customer's security questionnaire all ask the same question in different words: show me that access was removed within your stated timeframe, for these named people, on these dates. That is a reporting job on top of the workflow, not a by-product of it.
And somebody has to follow the reclaim through to the invoice. The seat freed by the workflow is a saving only when the subscription quantity comes down. Between those two events sits a renewal date and a conversation with finance, which is where most reclaim work quietly dies. Our guide to proving cloud cost savings covers why that last step needs a before and after rather than an assertion.
None of that is an argument against building the workflows. Build them this month. It is an argument for being clear that the automation solves the execution problem and leaves the ownership problem exactly where it was.
Where EtherInsights fits
EtherInsights is the console that sits over the top of this. It checks offboarding continuously rather than per ticket, surfaces leavers who are still enabled or still licensed as findings with a named owner and a next action, and keeps the before and after so a reclaim arrives at your finance review as evidence rather than a claim. Where you have Lifecycle Workflows, it tells you whether the workflows actually did what you designed them to do. Where you do not, because the governance licence has not been signed off yet, it gives you the same visibility without one.
Microsoft 365 licence management and offboarding runs the joiner, mover and leaver loop as one process across tenants, with the dormant-seat work from finding unused licences in the same view. It is £0.79 per active user with a 14-day trial, so you can measure the gap between your leave dates and your licence removals before committing to anything, which is usually the number that settles the argument.
Set the leave date properly, build the three scheduled workflows, script the mailbox, and put a monthly review in the calendar. If that review keeps slipping, you have found the real constraint, and it was never the tooling.
Explore Microsoft 365 licence management and offboarding to see leaver checks, licence reclaim and the evidence trail handled as one continuous process instead of a workflow nobody is watching.