Automating Leaver Offboarding with n8n

Offboarding is where identity work gets sloppy. The account gets disabled today, the group memberships get cleaned up next week if someone remembers, and the only record of what happened lives in whoever's memory did the work. I built a leaver automation in my home lab to close that gap: file a ticket in InvGate, and the disable, the group removal, and the audit trail all happen without anyone touching Active Directory by hand.

I recorded a walkthrough of the finished workflow and put the build on GitHub:

• Demo video: youtu.be/nvUdJd9x_AE
• Repo: github.com/TimothyHoag/Invgate---Leaver-Automation---IAM

The Problem I Was Trying to Solve

Manual offboarding across separate systems creates predictable gaps: delayed account disablement, group memberships that never get fully removed, and no reliable way to tell whether a leaver was actually completed short of asking around. In production environments supporting 30+ institutions, that gap is exactly where stale access and audit findings come from. I wanted to see what it takes to close it with the tools I already run in my lab: InvGate for ticketing, n8n for orchestration, and Active Directory as the system being acted on.

How the Workflow Runs

The trigger is the ticket itself, not a separate form. A requester files an "Employee Termination" ticket in InvGate with the employee's name, username, manager, and last day. An InvGate automation rule fires on ticket creation and calls an n8n webhook, authenticated with a shared header secret, passing those fields along with the ticket's request_id.

From there, n8n runs the rest:

1. Set Leaver Data maps the webhook payload into the fields the workflow needs.
2. n8n posts a "ticket received" comment back to the InvGate ticket, confirming the automation started.
3. The AD account gets disabled over SSH (Disable-ADAccount), and a confirmation comment lands on the ticket.
4. Group memberships get removed (Remove-ADGroupMember), with another comment confirming it.
5. A "leaver complete" comment closes out the ticket's audit trail.
6. A Slack notification goes to the relevant channel.
7. Every step's result, including failures, gets logged.

Why the Ticket Stays the System of Record

The part I cared most about wasn't the disable/remove mechanics; that's a few PowerShell commands over SSH. It was making sure the automation left a trail that actually holds up. Instead of spinning up a separate log or a new ticket for the automation's activity, every step comments back on the same InvGate ticket that triggered it. Intake, disable, group removal, completion: all of it sits on one record instead of being split across a ticket and a script log nobody checks.

That decision also shaped the failure handling. I tested what happens when the workflow points at a username that doesn't exist: the "ticket received" comment still posts, but the disable step fails, and that failure shows up both in the n8n execution log and as a gap in the expected comment sequence on the ticket. Nothing silently succeeds, and nothing silently disappears. An operator looking at the ticket can tell exactly where the automation stopped and why.

What This Demonstrates

This build isn't meant to be a finished product; it's a working demonstration of connecting IAM controls to ITSM records instead of treating them as two separate systems that happen to describe the same event. The same pattern (ticket as trigger, comments as audit trail, disable-before-cleanup as sequencing) applies whether the target is on-prem AD, Entra ID, or a SaaS app with an admin API.

The full walkthrough, including the failure path demo, is in the video linked above, and the workflow export and documentation are in the repo if you want to see the node-by-node build.

This project runs in my personal home lab against a test Active Directory domain and demo accounts; no production identities or organizational data are involved.