How to Automate Microsoft 365 Deprovisioning: A Step-by-Step Guide for HR and IT

Microsoft 365 deprovisioning is the single most time-sensitive security action in any employee offboarding sequence — and it is the one most likely to fail when left to manual processes. A departed employee with active M365 credentials retains access to email, OneDrive, SharePoint, and Teams until someone remembers to file an IT ticket. That window is a liability, not an oversight. This guide shows you exactly how to close it using automated automated employee offboarding workflows in Make.com™ — from the HRIS termination trigger through license reclamation — so the process runs without human intervention every single time.

Before You Start: Prerequisites, Tools, and Risks

Before building the scenario, confirm these prerequisites are in place. Missing any one of them will cause the workflow to fail silently or incompletely.

What You Need

  • Make.com™ account — Business plan or above recommended for multi-module scenarios with error handling.
  • Microsoft 365 tenant — Global Admin or a delegated service account with User.ReadWrite.All, Directory.ReadWrite.All, Organization.Read.All, and Mail.ReadWrite permissions granted in Azure AD.
  • HRIS with outbound webhook or API access — BambooHR, Workday, ADP Workforce Now, and most enterprise HRIS platforms support this. Confirm your tier includes API access before building.
  • Audit log destination — A database table, Google Sheet, or SIEM endpoint outside the M365 tenant to receive timestamped action logs.
  • Sandbox/test account — A non-production M365 account dedicated to scenario testing. Never test deprovisioning steps against a live user account.

Time Required

Initial build: 3–5 hours for a standard deprovisioning scenario. Add 1–2 hours for each conditional branch (e.g., voluntary vs. involuntary termination routing). Testing and validation: 2–4 hours.

Key Risks to Manage

  • False-positive terminations: HRIS data errors can fire a termination event for an active employee. Build a confirmation gate before any irreversible action.
  • Incomplete group membership removal: Account disable does not automatically remove the user from Teams channels or SharePoint site collections. This must be an explicit step.
  • OneDrive data loss: Disabling and then deleting an account without transferring OneDrive content first results in permanent data loss. Sequence matters.
  • API rate limits: Microsoft Graph enforces throttling. For bulk offboarding events, build retry logic and error handlers into every API call module.

Step 1 — Configure the HRIS Termination Trigger

The workflow begins the moment your HRIS records a termination. The trigger is the most important architectural decision in the entire scenario — get this wrong and everything downstream either fires too early, too late, or not at all.

Option A — Webhook (preferred): Configure your HRIS to POST a webhook payload to Make.com™ when an employee’s status changes to “Terminated” or equivalent. In Make.com™, create a new scenario and add a Webhooks module as the trigger. Copy the generated webhook URL into your HRIS outbound notification settings. The payload should include at minimum: employee ID, full name, M365 UPN (user principal name), manager email, termination date, and termination type (voluntary/involuntary).

Option B — Scheduled polling: If your HRIS does not support outbound webhooks, add a Make.com™ HTTP or HRIS-native module on a 15-minute schedule that queries for status changes since the last run. Filter results where status = terminated AND termination_date = today. This is less real-time but fully functional.

Confirmation gate: Immediately after the trigger, add a Make.com™ Sleep module set to 20 minutes, followed by a notification to an IT admin with an abort link. This gate prevents a false-positive termination from executing irreversible actions on an active employee’s account. After the window closes without an abort signal, the scenario proceeds automatically.

Step 2 — Disable the Microsoft 365 Account

Account disable is the first and most urgent action. Everything else in the workflow depends on this step completing successfully.

Add a Make.com™ HTTP module configured to call the Microsoft Graph API PATCH endpoint:

PATCH https://graph.microsoft.com/v1.0/users/{UPN}
Body: { "accountEnabled": false }

Map the UPN value from the HRIS trigger payload. Set the module’s OAuth 2.0 connection using your service account credentials with the required Graph API permissions.

Add an error handler (the wrench icon on the module) with a Rollback or Resume path. If the API call fails — due to a permission error or throttling — the error handler should write a failure record to your audit log and send an immediate alert to IT. Do not let a failed disable step pass silently.

Verify the step by checking the module’s output bundle for "accountEnabled": false in the response. Log the timestamp and the response status code to your audit destination.

Step 3 — Revoke Active Sessions and Refresh Tokens

Disabling the account blocks new sign-ins but does not immediately terminate active sessions. A user already authenticated to Teams or SharePoint retains access until their token expires — potentially for hours. Revoke all active sessions explicitly.

Add a second HTTP module calling:

POST https://graph.microsoft.com/v1.0/users/{UPN}/revokeSignInSessions

This call invalidates all refresh tokens and forces immediate re-authentication on any active client. Combined with the account disable in Step 2, access is terminated for both new and existing sessions within minutes. This is the step that closes the security gaps that automated workflows are specifically designed to stop.

Log the API response and timestamp. A 200 OK response confirms all tokens are revoked.

Step 4 — Set Up Email Forwarding and Auto-Reply

Business continuity requires that emails sent to the departed employee’s address reach the right person. Set this up before the account enters a state where mailbox access becomes restricted.

Email forwarding: Use the Graph API to set the forwardingSmtpAddress on the user’s mailbox settings, pointing to the manager email address from the HRIS payload:

PATCH https://graph.microsoft.com/v1.0/users/{UPN}/mailboxSettings
Body: { "forwardingSmtpAddress": "{managerEmail}", "automaticRepliesSetting": { "status": "AlwaysEnabled", "internalReplyMessage": "...", "externalReplyMessage": "..." } }

Map the auto-reply message text from a Make.com™ text template module so the message is consistent across all offboarding events. Include the manager’s name and contact information in the reply body.

This step is skipped in the majority of manual processes because it requires mailbox-level API access that IT teams don’t always expose to HR. Automation makes it a default, not an exception — directly eliminating the class of offboarding errors that stem from missed communication continuity.

Step 5 — Transfer OneDrive Content and Preserve SharePoint Access

OneDrive content preservation is the step organizations most frequently defer — and the deferral is almost always a governance failure waiting to surface. Execute this before the account is moved to a deleted state.

Use the Graph API to initiate a OneDrive transfer to the manager:

POST https://graph.microsoft.com/v1.0/users/{UPN}/drive/root/copy
Body: { "parentReference": { "driveId": "{managerDriveId}" }, "name": "{employeeName}_Archive" }

The copy operation is asynchronous. Add a Make.com™ polling loop (or a webhook from Graph’s async operation callback) to confirm completion before proceeding. If the copy fails, write a critical alert to the audit log and halt the workflow pending manual IT review.

For SharePoint site ownership, query the user’s site collection memberships via Graph and transfer ownership to the manager or a designated IT service account. Remove the departing employee from contributor and owner roles on all sites. This prevents a disabled-but-still-listed user from appearing as an active collaborator in SharePoint’s directory.

Step 6 — Remove Group Memberships and Teams Access

This is the step that separates a complete deprovisioning workflow from a partial one. Account disable does not cascade to group membership. The user remains a listed member of every Teams channel, shared mailbox, distribution list, and Microsoft 365 Group they belong to until explicitly removed.

Query the user’s group memberships:

GET https://graph.microsoft.com/v1.0/users/{UPN}/memberOf

The response returns an array of group objects. Add a Make.com™ Iterator module to loop through each group and call the remove-member endpoint for each one:

DELETE https://graph.microsoft.com/v1.0/groups/{groupId}/members/{userId}/$ref

Apply the same pattern to Teams channel membership using the Teams-specific Graph endpoints. This sweep also covers distribution lists, which are often forgotten entirely in manual processes. Pair this with automating IT asset recovery for a fully coordinated equipment and access closure on the same day.

Step 7 — Reclaim Microsoft 365 Licenses

License reclamation is a direct cost-recovery step. Every day a departed employee’s license sits assigned to a disabled account is a day of per-seat cost with zero return. Automate reclamation as part of the same scenario.

First, retrieve the user’s assigned license SKUs:

GET https://graph.microsoft.com/v1.0/users/{UPN}/licenseDetails

Then remove all assigned licenses in a single call:

POST https://graph.microsoft.com/v1.0/users/{UPN}/assignLicense
Body: { "addLicenses": [], "removeLicenses": ["{skuId1}", "{skuId2}"] }

Map the SKU IDs dynamically from the license details response using Make.com™’s array aggregator. This handles users with multiple license assignments (E3 plus add-ons, for example) without requiring hardcoded SKU values that become stale as your tenant evolves.

Log the specific SKUs reclaimed and the reclamation timestamp. This data feeds your monthly license cost reconciliation and provides documented evidence for IT audits.

Step 8 — Write the Complete Audit Log

Every action in the workflow must produce a written record in a system outside the M365 tenant. This is not optional for offboarding compliance and audit risk reduction — regulators and auditors expect documented, timestamped evidence of access revocation.

At the end of the scenario, add a data store write or HTTP POST to your audit destination. Each record should include:

  • Employee ID and full name
  • Termination date and type
  • Timestamp of each action (disable, token revoke, forwarding set, OneDrive transfer, group removal, license reclaim)
  • API response status for each action (success, failure, partial)
  • Make.com™ scenario execution ID for cross-reference

For organizations subject to SOC 2, GDPR, or CCPA, store audit records for a minimum of 12 months and ensure the storage system has its own access controls and backup policy. Gartner research consistently identifies access control documentation as a primary audit finding in identity governance reviews.

Step 9 — Send Completion Notifications

Close the workflow with targeted notifications to confirm the deprovisioning is complete.

Add a Make.com™ Email or Teams message module to notify:

  • IT security: Full action summary with execution ID and any error flags.
  • HR: Confirmation that M365 access has been fully revoked, timestamped for the employee’s offboarding record.
  • Manager: Confirmation that email forwarding is active and OneDrive content has been transferred to their drive.

Keep notification content factual and audit-ready. The notifications themselves serve as secondary evidence of process completion and should be retained alongside the formal audit log.

How to Know It Worked: Verification Checklist

After the scenario executes against your test account, confirm each of the following before deploying to production:

  • ☐ Test account cannot sign in to any M365 service (Outlook, Teams, SharePoint, OneDrive)
  • ☐ Active sessions were invalidated — confirm by checking Azure AD Sign-In Logs for the test UPN
  • ☐ Email sent to the test address arrives in the manager’s inbox via forwarding
  • ☐ Auto-reply is returned to the sending address
  • ☐ OneDrive archive folder appears in the manager’s drive
  • ☐ Test account is absent from all M365 Groups, Teams channels, and distribution lists
  • ☐ License details for the test account show zero assigned SKUs
  • ☐ Audit log contains a complete record with timestamps for every action
  • ☐ IT, HR, and manager notifications were received
  • ☐ Error handler fired correctly when tested with a deliberately invalid UPN

Do not move to production until every item on this list is confirmed. A partial pass means the workflow has gaps that will surface — and fail — on a real termination event.

Common Mistakes and How to Avoid Them

Mistake 1: Skipping the Confirmation Gate

Building a workflow that immediately executes on the HRIS trigger without a pause is a single-point-of-failure. HRIS data errors happen. The 20-minute confirmation gate costs nothing in real termination scenarios and prevents catastrophic false-positive deprovisionings.

Mistake 2: Treating Account Disable as Complete Deprovisioning

Disabling the account is step one, not the finish line. Active session tokens, group memberships, and license assignments all survive an account disable. The workflow must execute every subsequent step to constitute a complete and defensible deprovisioning.

Mistake 3: No Error Handling on API Calls

Microsoft Graph API calls fail. Throttling, permission errors, and transient network issues all cause failures. Every HTTP module in the scenario needs an error handler that writes to the audit log and fires an alert — not a silent failure that leaves the deprovisioning half-complete.

Mistake 4: Hardcoding License SKU IDs

License SKU IDs change when Microsoft updates product bundles or when your tenant adds new subscriptions. Hardcoding them means the license removal step silently fails for users on newer SKUs. Always query and map SKU IDs dynamically from the license details response.

Mistake 5: Storing the Audit Log Inside M365

An audit log stored in SharePoint or a M365 Teams channel is controlled by the same tenant that’s being deprovisioned. That log can be altered or lost. Store it externally — always.

Next Steps: Expand the Automation Beyond M365

Microsoft 365 deprovisioning is one lane of a complete offboarding automation architecture. The same Make.com™ scenario that fires the M365 sequence can simultaneously branch to handle Salesforce deactivation, HRIS status updates, and payroll finalization. Review what a fully automated offboarding compliance program looks like across all systems, and see how stopping payroll errors through offboarding automation closes the financial side of the same exit event.

The risks of doing this manually are documented. According to Parseur’s Manual Data Entry Report, manual data processes cost organizations an average of $28,500 per employee per year in combined labor and error-correction costs — and access management errors are among the most expensive to remediate after the fact. Automation isn’t an upgrade to the manual process; it replaces the risk profile entirely.

If you want to understand the full business risk of poor offboarding practices before building, start there. If you’re ready to build, the steps above are your production-ready blueprint.