Secure Employee Offboarding Automation for Microsoft 365
IT Partner builds a repeatable, audited leaver process in your Microsoft 365 tenant: HR or a manager submits a termination request in a SharePoint list, the approvers you name sign it off in Microsoft Teams, and at the effective time a Power Automate flow carries out the offboarding through Microsoft Graph — sign-in blocked and the password reset, sign-in sessions revoked, multifactor methods removed, group memberships removed and sole ownership of Teams and Microsoft 365 Groups handed to the manager, the mailbox converted to a shared mailbox with forwarding and an auto-reply, OneDrive access delegated, the license released on schedule, HR, the manager and IT notified, every step written to an audit register, and the account deleted at the end of the retention window you chose. You get the request form, the approval, both flows, the runbook and one month of break-fix for $1,450 per project, fixed, delivered in two weeks. It needs no Microsoft Entra ID Governance license — that is the point; tenants that license Governance for every user should use Entra lifecycle workflows instead, and we say so. The Microsoft licenses the automation runs on — Power Automate Premium for the flow owner and, where the Exchange step runs unattended, a small amount of Azure Automation consumption — are yours, at Microsoft's price.
What this engagement is
In most 25-to-500-user organizations the leaver process is a checklist. HR emails IT, someone blocks the account when they see the email, the mailbox question is settled a week later, and the license is found still assigned at the next true-up. Every step is known; the gap is that they happen in whatever order, on a human's timetable, with no record that they happened at all. That gap is what a cyber-insurance questionnaire or an auditor is asking about when it asks how quickly a departing employee's access is removed — and it is exactly the window a still-valid token or a forgotten group membership lives in. We replace the checklist with one approved event. The request lives in a SharePoint list (with Microsoft Forms in front of it if HR prefers a form): who is leaving, their last day and effective time, their manager, what happens to the mailbox and OneDrive, the auto-reply text, and how long to keep the account before deletion. Approval runs through Approvals in Microsoft Teams to the people you name — HR plus the leaver's manager by default — and nothing executes until it is granted. At the effective time an automated Power Automate flow works through the steps against Microsoft Graph in a fixed order: block sign-in and reset the password, revoke sign-in sessions so refresh tokens die, remove the registered multifactor methods (which also takes the leaver's personal phone number out of your tenant), remove group memberships, move sole ownership of any Team or Microsoft 365 Group to the manager, grant the manager access to the OneDrive, list the leaver's registered devices for IT, and write each result to the register with a timestamp. One step Microsoft Graph cannot do — converting the mailbox to a shared mailbox with forwarding and the auto-reply — is an Exchange Online PowerShell operation: it runs unattended as an Azure Automation runbook under a managed identity where you have an Azure subscription, or is handed to IT as a checklist task with the exact commands where you do not. A second, scheduled flow works the dated steps off the register — license removal once the mailbox is converted, deletion at the end of the retention window — because a single flow run cannot wait for weeks. The flow acts through a dedicated app registration in your tenant that holds only the application permissions its steps need, listed in the runbook, with a credential you keep — never a stored administrator password, and never our access: we build under the time-bound, least-privilege delegated access you approve, and remove ourselves at handover. Two boundaries, stated plainly. This is the deliberate alternative to Microsoft Entra lifecycle workflows for tenants that do not license Microsoft Entra ID Governance for every user; if you do, lifecycle workflows are the better-integrated answer and we will tell you so at the first call. And it automates the Microsoft 365 side of leaving: retention and legal holds on the leaver's data, device wipe policy, and deprovisioning in applications that keep their own accounts are separate decisions with their own services, linked below.
Success criteria
What you receive
How the work unfolds
We walk through your current checklist and turn it into decisions: who may request, who approves, the default handling for mailbox, OneDrive and Teams ownership, the retention window, what the auto-reply says, and whether the Exchange step runs unattended in Azure Automation or as a task to IT. We check whether accounts are cloud-only or synced from on-premises Active Directory, whether any leaver could hold an admin role, and confirm the Power Automate license for the flow owner. The decisions go in writing before anything is built.
We create the app registration with the application permissions the steps need and nothing more, with the credential in your keeping; the Azure Automation account and managed identity with Exchange rights where the Exchange step runs unattended; the requester and approver groups; and the flow-owner account. Everything is recorded in the runbook as we go.
The SharePoint list and optional Forms front end, the Teams approval, and the offboarding flow with its fixed step order, exception handling and register writes; the Exchange runbook or IT task; and the scheduled flow for license removal and deletion. Test mode is built in from the first run so nothing touches a real account before you say so.
Two test leavers run end to end while you watch — one with mailbox retention, one without: sign-in blocked, sessions revoked, methods gone, groups and ownership moved, mailbox converted with forwarding and auto-reply, OneDrive delegated, notices delivered, register complete. We also exercise a rejection, a deliberately failed step, and a restore from soft delete.
A working session with IT and HR: how to submit, approve, read the register, re-run a step, change approvers and defaults, and restore an account. The runbook is delivered, acceptance is confirmed against the success criteria, and any temporary access we held is removed.
For one month after closure we fix anything in the delivered solution that does not behave as documented, at no charge. Changes to scope — new fields, new steps, systems outside Microsoft 365 — are quoted separately.
Prerequisites
Who does what
IT Partner
- Turn your checklist into the request form, approval and flow design, and put the decisions in writing before building
- Create the app registration, permissions, connections and, where used, the Azure Automation runbook, with the credential in your keeping
- Build and test the request form, approval, offboarding flow, Exchange step, scheduled flow, notifications and register
- Deliver the runbook and the handover session, and remove any temporary access we were granted
- Provide break-fix support for the delivered solution for one month after project closure
Your team
- Name the requester and approver groups, the default handling for mailbox, OneDrive and retention, and the auto-reply wording
- Provide the Power Automate license for the flow owner and, where the Exchange step runs unattended, the Azure subscription
- Provide delegated access for the build and two test accounts, and attend the test runs and the handover
- Own the process afterwards: submit and approve leaver requests, read the register, and keep the manager attribute current
- Pay Microsoft for the licenses and any Azure consumption the automation uses
What's not included
Limitations & technical notes
Frequently asked questions
What happens the moment a leaver's request is approved?
Nothing until the effective time on the request; then the steps run in a fixed order. Sign-in is blocked and the password reset, sign-in sessions are revoked so refresh tokens die, the registered authentication methods are removed, group memberships are removed, sole ownership of Teams and Microsoft 365 Groups moves to the manager, the manager gets OneDrive access, the mailbox is converted to shared with forwarding and the auto-reply, and each step's result lands in the register before the notices go out. Lockout comes first because it is the step that matters if anything later fails. Already-issued access tokens can live up to about an hour in applications without continuous access evaluation — Microsoft's token design — which is why we recommend a scheduled effective time rather than a same-minute surprise.
Do we need Microsoft Entra ID Governance or a P2 license for this?
No — that is the reason this service exists. Microsoft's own leaver automation, lifecycle workflows, requires a Microsoft Entra ID Governance license (or Microsoft Entra Suite) for every user a workflow runs against, not just for the administrators who build it. This service uses Power Automate and Microsoft Graph, which your Microsoft 365 licenses already permit, plus a Power Automate Premium license for the flow owner. If you already license Governance tenant-wide, lifecycle workflows are the better-integrated answer and we will say so at the first call rather than build a parallel path.
Which licenses does the automation itself need, and who pays for them?
The flow uses premium connectors — the Microsoft Entra ID connector, HTTP calls to Microsoft Graph and, where used, the Azure Automation connector — so the account that owns the flows needs Power Automate Premium, which Microsoft lists at $15 per user per month at the time of writing, or the flows sit under a Power Automate Process plan. Where the Exchange step runs unattended, Azure Automation meters a small amount of runtime on your subscription. These are Microsoft's licenses and charges: you buy them at Microsoft's price, directly or through our CSP, and they are not in the $1,450.
Can Microsoft Graph convert the mailbox to a shared mailbox?
No. Microsoft Graph can set the auto-reply and an inbox rule, but changing the mailbox type is only exposed through Exchange Online PowerShell (Set-Mailbox with the Shared type), and forwarding is cleanest there too. We therefore build one Exchange step that converts, forwards and sets the auto-reply together. It runs unattended as an Azure Automation runbook under a managed identity with Exchange rights where you have an Azure subscription; where you do not, the flow assigns that one step to IT with the exact commands, waits for it to be marked done, and continues. Either way the result is recorded in the register.
What happens to the leaver's mailbox, and do we keep paying for it?
If the request says keep it, the mailbox becomes a shared mailbox: the forwarding address and auto-reply from the request are applied, the manager or a delegate is given access, and once conversion is confirmed the scheduled flow removes the license — a shared mailbox under 50 GB with no archive and no hold needs none. The leaver's account stays, blocked, because Microsoft requires it to anchor the shared mailbox; deletion waits until the retention window on the request ends. A mailbox over 50 GB, with an archive, or under a litigation or Purview hold needs the Exchange Online license Microsoft specifies, and we tell you which before the run. If the request says do not keep it, the license comes off and the mailbox goes with the account at deletion.
What happens to their OneDrive files?
At offboarding time the flow grants the manager, or the delegate named on the request, access to the leaver's OneDrive, so files can be moved while the account is blocked but still present. When the account is later deleted, Microsoft's OneDrive retention for deleted users takes over: the manager or the secondary owner set in the SharePoint admin center gets access for the configured period — 30 days by default, adjustable — before the OneDrive is deleted. We align that setting and the secondary owner during the build. What must be kept and for how long is a retention decision, which is Purview scope.
Our accounts sync from on-premises Active Directory. Does this still work?
Mostly, with one honest exception. Session revocation, authentication-method removal, group and ownership changes, OneDrive delegation, the mailbox step, notifications and the register all work for synced accounts. The disable itself does not stick in the cloud: Entra Connect writes the on-premises enabled state back over it on the next sync cycle, so the account must be disabled in Active Directory. The flow assigns that step to IT, or we automate it through an Azure Automation Hybrid Runbook Worker as a separately quoted addition; where you license Microsoft Entra ID P1, we also add the leaver to a Conditional Access block group as an immediate bridge.
Who can submit a request, and who approves?
Submission is limited to a group you name — usually HR and people managers — through the SharePoint list's permissions or the Forms front end. Approval goes through Approvals in Microsoft Teams to the approvers you name, by default HR plus the leaver's manager from the request, and the decision, approver and time are written to the request. A request nobody approves does nothing. A second approval stage or per-department approvers is a customization, quoted separately.
What if the leaver owned Teams, or held an admin role?
Teams and Microsoft 365 Groups the leaver owned alone get the manager as owner before the leaver is removed, so nothing becomes ownerless; groups with other owners simply lose the leaver. Distribution lists are handled in the Exchange step. An account holding a Microsoft Entra administrator role is different: the flow stops, tells IT, and does not act on it — removing a privileged account is a human decision, and the app registration is deliberately not granted the permissions to touch privileged accounts.
When is the account actually deleted, and can we get it back?
At the end of the retention window recorded on the request — the default is yours to set; 30 or 90 days are common — by the scheduled flow, and only once the shared mailbox is no longer being retained. Deletion is Microsoft's soft delete: the account can be restored from the Microsoft Entra admin center for 30 days, with its mailbox and OneDrive, and the runbook has the restore procedure. After that the account is permanently gone; a mailbox under a Purview retention policy or hold becomes an inactive mailbox instead.
What access do you need to build it, and what runs the flow afterwards?
During the build, time-bound, least-privilege delegated (GDAP) access that you approve — the roles for Entra, Exchange, SharePoint and Power Platform for the two weeks, removed at handover; we do not hold standing global admin. Afterwards the flow runs under a dedicated app registration in your tenant with only the application permissions its steps need and a credential you keep, plus a managed identity for the Exchange runbook where used. No administrator password is stored in any connection, and nothing depends on IT Partner being present: if you stop working with us, it keeps running.
What counts as a customization?
The fixed price covers the standard request and step set on this page. Extra form fields, additional approval stages, per-department or per-country branches, deprovisioning in an application with its own user store, the on-premises Active Directory step for synced accounts, or an Intune retire action for corporate devices are all possible and are quoted separately — the same rule as our onboarding service. Tell us what your checklist has that this page does not, and we price the difference with the quote.
How is pricing determined?
$1,450 per project, fixed, for the scope on this page, quoted in writing before work begins; you pay after you approve delivery. It includes the form, the approval, both flows, the Exchange step, the app registration, the runbook, two witnessed test runs, the handover and one month of break-fix on the delivered solution. Microsoft's licenses and metered charges are separate and yours. Organizations that buy their Microsoft licensing through IT Partner also have unlimited business-hours break-fix support included, which continues to cover the delivered flow after the first month; changes and additions remain quoted work.
How does this relate to your employee onboarding service?
It is the mirror of New Employee Onboarding with Approvals and Notifications: the same SharePoint-list-and-approval pattern, the same runbook and one-month break-fix style, pointed at the leaver path — which has more steps and a retention decision, hence the higher fixed price. Built together they give HR one place to request both events. The broader version of the pattern — any approval-driven process on Microsoft 365 — is our Business Process Automation service, and the approval mechanics are explained in our guide Build an Approval Process with Power Automate.