Practical How-To

48% of IT Teams Worry About Missed Offboarding Steps. Here's the n8n Workflow That Fixes It.

By Felix Maru · May 8, 2026 · 7 min read

When someone left a remote office in Mombasa or Kisumu, I'd often get a WhatsApp message from the county coordinator before I ever saw an official HR notification. By the time the formal email arrived — if it arrived at all — the person had sometimes held active Microsoft 365 credentials for another week or two.

I managed IT for a large international NGO operating across Kenya. 31 counties. Over 300 staff. When offboarding was entirely manual, we tracked our access-closure rate for a quarter and found we were hitting roughly 70% within 48 hours of a departure. The remaining 30% were almost always remote staff, where local coordination added lag and the checklist got lost in someone's inbox.

One case stayed with me: an employee left for a competitor and had an active email account for three weeks because the departure notification never reached IT. Nothing catastrophic happened. But it easily could have.

That pattern is not unique to NGOs. According to data published in 2025, the average annualised cost of insider-related incidents is roughly $17 million, with credential theft and malicious insiders together accounting for nearly half of cases. Separately, around 48% of IT teams say they worry that missing offboarding steps leave their organisation exposed — a number I find entirely believable from personal experience.

The fix isn't a more detailed checklist. It's removing humans from the trigger.

What Offboarding Actually Needs to Do

Before building any automation, I made a list of every action that needed to happen when someone left. Most IT teams have a version of this:

None of this is complicated. The problem is execution. When each step lives in a different admin portal and requires a separate manual action, the checklist exists but completion is inconsistent. Nobody is being careless — the work is just fragmented across too many systems with no single owner watching the clock.

The Architecture: One Trigger, One Workflow

The solution I now run at a top US-based company I work with is straightforward in concept: the HR system is the single source of truth, and any departure event in HR fires an n8n workflow automatically, without anyone touching it.

Here's how the workflow is structured:

Step 1 — The trigger. The ideal setup is a webhook from your HRIS that fires the moment an employee record is marked for departure. If the HRIS doesn't support webhooks (common in older systems), a Schedule node in n8n polls a shared HR spreadsheet or Airtable every hour and checks for new rows flagged "offboarding." Either way, the workflow starts without waiting for someone to remember to start it.

Step 2 — Disable the account. n8n's Microsoft Active Directory node, or an HTTP Request node pointed at the Microsoft Graph API, disables the user account immediately. This is the critical step. Everything else can wait hours. The account cannot. Sign out all active sessions at the same time using POST /users/{id}/revokeSignInSessions.

Step 3 — Revoke the M365 licence and set mail forwarding. Three Graph API calls: remove the licence assignment, enable mail forwarding to the manager, and set an out-of-office reply. Combined, this takes under two minutes to configure in n8n and runs in seconds.

Step 4 — Notify stakeholders with a structured checklist. A Slack or Teams message (or a Help Scout ticket if internal requests route through support) goes to IT, the manager, and HR. It confirms that the account is disabled and lists every remaining manual step — device retrieval, physical access cards, shared credential rotation — as a formatted checklist. The notification is the handoff, not a request to start.

Step 5 — SaaS suspension queue. For tools with APIs (Pipedrive, HubSpot, Zendesk, Help Scout, Smartlead), add HTTP Request or native nodes to suspend the account. For tools without APIs, the Step 4 notification includes a list of manual actions with direct admin panel links pre-populated. You won't automate every SaaS app — don't try to on the first build. Add them one at a time as you encounter them.

Step 6 — 24-hour follow-up. A Wait node fires a follow-up message the next day confirming that physical asset recovery and any manual steps are complete. If nobody has marked them done, the reminder goes out again at 48 hours. The loop stops when IT manually closes the ticket or marks the checklist complete.

The full workflow takes roughly half a day to build end-to-end the first time, including testing. After that, it runs without any human intervention on the trigger-to-account-disabled path.

What You Still Can't Automate

Two categories consistently resist full automation, and trying to pretend otherwise creates false confidence.

The first is physical assets. Laptops, headsets, hardware MFA tokens — automation can track and remind, but it cannot retrieve. I have seen offboarding workflows considered "complete" the moment accounts are closed, which leaves thousands of dollars of equipment unaccounted for and hardware MFA tokens potentially still usable. The workflow must generate a hardware checklist and keep nudging until a human marks each item done.

The second is shared credentials. If the departing employee held a shared password — a social media account login, a billing portal, a shared inbox — those credentials need rotating, not just removing from the person's password manager. The workflow should flag any shared-credential items associated with the user and generate an explicit task for manual rotation. Don't assume it's handled; build the assumption in that it is not.

Automate the predictable path completely. For anything that doesn't fit, generate an explicit human task — not a hope that someone will remember.

This design principle applies beyond offboarding. The point of a good automation isn't to eliminate human judgement; it's to eliminate human memory as a dependency for the steps where memory shouldn't matter.

After Automation, the Numbers

Since the current workflow has been running, access deactivation on the departure date has moved from roughly 70% compliance to consistently above 95%. The remaining gaps are edge cases: public holidays, last-minute departures where HR hadn't updated the record before end of day, or off-cycle contractors not tracked in the main HRIS.

The time burden on IT dropped from around 40 minutes per offboarding — tracking down accounts, emailing managers, manually working through the checklist — to under five minutes for exception handling when something requires human review. That doesn't sound dramatic until you account for every hire-and-exit cycle across a year at a company with real staff turnover.

There's also a less measurable benefit: confidence. When an auditor or a security review asks "how do you handle access revocation on departure," the answer is no longer "we have a process." It's "here's the workflow log."

How to Start If You're Not There Yet

If your current offboarding process is a shared checklist in Google Sheets and a chain of emails, here's the minimum viable version that moves the needle quickly:

  1. Get HR to own a single departure signal. One email, one Slack message, one ticket — the format doesn't matter, but there must be one place where a departure is formally signalled. That becomes your n8n trigger. Without this, nothing else works.
  2. Automate the AD/Entra disable first. It's the highest-risk step and the easiest to automate via Microsoft Graph. Get that one action off the manual checklist before anything else. The API call is four lines of JSON in an HTTP Request node.
  3. Build the notification before the full workflow. If you can't automate the disable yet, at minimum build a workflow that catches the departure signal and sends a pre-formatted checklist to the IT inbox. You've removed the "I forgot to start" failure mode immediately.
  4. Add SaaS suspension one tool at a time. Each SaaS tool with an API is a 20–30 minute addition to the workflow. Add them across several sprints rather than trying to cover every app in the first build.
  5. Measure before and after. Track your access-closure rate for a month before you build, then again a month after. Visibility into the gap is what usually turns this from "nice to have" into "this needs to happen this sprint."

The goal isn't a perfect offboarding machine on day one. It's a workflow that handles the critical path automatically and makes the remaining manual steps impossible to miss — because they show up as a structured checklist in the right person's inbox, not as an item someone is expected to remember.

If you're setting this up and want a second opinion on the workflow design or Graph API structure, get in touch. The architecture is generally the same across environments — the gotchas are in the edge cases, and I've hit most of them already.

Share 𝕏 in ✉

Comments