Automated offboarding closes the gap between an employee’s last day and the moment their access disappears. A Make.com workflow triggered by your HRIS termination event locks accounts, recovers data, wipes devices, and generates a full audit trail — all within minutes of a confirmed termination.

Every enterprise invests heavily in perimeter defenses — firewalls, endpoint detection, phishing simulations. Then an employee gives two weeks’ notice, and the access review goes into a ticketing queue. By the time IT processes the request, that employee has had 36 unmonitored hours inside systems containing your client database, your product roadmap, and your payroll records. The breach vector isn’t the external attacker. It’s the gap between “last day” and “access revoked.”

This guide shows you exactly how to close that gap with a deterministic, automated offboarding security workflow built in Make.com. If you’re approaching this for the first time, start with the strategic case for offboarding automation as your first HR project — then come back here for the execution blueprint.

Before You Start

Before you configure a single automation, confirm these prerequisites exist. Skipping them means building on a foundation that cracks under real-world conditions.

• System inventory: A documented list of every application, directory, cloud environment, and physical access system in your organization — with the owner of each.
• HRIS termination event: Your HRIS must emit a webhook or API call the moment a termination is confirmed. If it can’t, you need an integration layer between HR and Make.com.
• Identity provider (IdP) access: Admin credentials and API access to your SSO or directory — Okta, Azure AD, Google Workspace, or equivalent.
• DLP tooling: A data loss prevention solution integrated with your email, file storage, and endpoint management platforms.
• MDM solution: Mobile device management coverage for all company-issued hardware.
• Stakeholder alignment: HR, IT, Legal, and Finance must agree on the termination trigger definition. Voluntary and involuntary departures require different workflow branches.
• Time investment: Plan for 40–80 hours of configuration and testing for a mid-market organization (200–1,000 employees). Larger enterprises with complex SaaS stacks should plan a phased rollout over 8–12 weeks.

Critical risk: Automation that locks out an employee before HR confirms the termination creates legal exposure. Build a human confirmation gate before the workflow fires in ambiguous situations — a leave of absence mis-coded as a termination, for example. The gate takes two minutes to add and prevents a lawsuit.

Step 1 — Map Every Access Point the Departing Employee Holds

You can’t revoke access you don’t know exists. Run a comprehensive access audit before writing a single automation rule.

Pull an access report from your identity provider. That gives you every application federated through SSO. Then cross-reference against three additional sources:

• Finance and procurement records: Any SaaS tool with a named license purchased on a corporate card. These are frequently invisible to IT.
• Manager interviews: Direct managers almost always know about role-specific tools — sales intelligence platforms, design tools, specialized databases — that IT doesn’t track.
• The employee’s own system inventory: In voluntary departures, a structured offboarding conversation surfaces tools the employee uses that nobody else knows about.

Build a master access registry. For each system, capture: system name, access type (admin / user / read-only), deprovisioning method (API, manual admin action, or SSO cascade), and the internal owner responsible for confirming revocation.

This registry becomes the source of truth your Make.com workflow runs against. Without it, your automation is incomplete by design.

If you haven’t done a structured process audit before, OpsMap™ is the discovery step that prevents automation mistakes — including the mistake of automating before you know what you’re automating.

Step 2 — Configure the HRIS Termination Trigger in Make.com

The trigger is everything. A delayed or unreliable trigger breaks the entire security case for automation.

In Make.com, set the entry point to a webhook that your HRIS fires when a termination record is confirmed. The webhook payload needs at minimum: employee ID, termination date, termination type (voluntary or involuntary), and the confirming HR manager’s name.

If your HRIS doesn’t support outbound webhooks natively, use a Make.com scheduled scenario to poll the HRIS API every 15 minutes for status changes. This is a fallback — push webhooks are faster and more reliable. Push for the webhook first.

Add a data validation step immediately after the trigger. Confirm the employee ID exists in your directory. Confirm the termination date is today or in the past. If either check fails, route to a Slack alert for manual review and stop the scenario. A false trigger that locks out an active employee is worse than no automation at all.

Step 3 — Execute the Immediate Lockout Sequence

This is the core of the workflow. The sequence below should complete in under three minutes from trigger to confirmation.

1. Disable the identity provider account. Suspend the user in your SSO/directory first. This cascades to every federated application simultaneously — a single API call that cuts off more access than anything else on the list.

2. Revoke active sessions. Disabling the account doesn’t terminate existing sessions already authenticated. Force-revoke OAuth tokens and active sessions in your IdP, email platform, and any high-risk SaaS tools that hold session state independently.

3. Reset all passwords. Even after account suspension, reset passwords on any system that doesn’t federate through SSO. This catches the tools employees access with saved credentials outside the corporate directory.

4. Remove multi-factor authentication devices. Deregister all MFA devices tied to the employee’s identity. A suspended account with a registered authenticator app is still a residual risk if the suspension is ever reversed incorrectly.

5. Revoke API keys and personal access tokens. Developers and ops-adjacent roles accumulate personal tokens across GitHub, AWS, internal tools, and third-party APIs. Pull a token audit from each platform and revoke every token associated with the employee’s identity.

6. Transfer email and calendar ownership. Forward the departing employee’s email to their manager or a designated HR inbox. Transfer calendar ownership so scheduled meetings don’t disappear. Do this before locking the account — order matters here.

Step 4 — Preserve Data and Wipe Devices

Locking accounts stops new exfiltration. This step closes the window on data already moved and recovers assets the company owns.

File storage audit. Trigger a DLP scan of the employee’s cloud storage folders — Google Drive, OneDrive, Dropbox, or wherever your stack lives. Flag any files shared externally in the 30 days before termination. Route the report to IT Security for review. This isn’t punitive; it’s documentation.

Email data preservation. Place a litigation hold on the departing employee’s mailbox before the account is fully disabled. Legal requires this in most involuntary terminations. Configure it as a parallel branch in Make.com so it fires simultaneously with the lockout sequence, not after.

Device remote wipe. Send the MDM wipe command for all company-issued devices. For involuntary terminations, fire this immediately. For voluntary departures, you have 24–48 hours while the employee completes return logistics — but the command should be queued and confirmed before the employee’s last day.

Credential vault sweep. If your organization uses a shared password manager (1Password, Bitwarden, LastPass), remove the departing employee from all shared vaults and rotate any credentials they had access to. This step is missed in nearly every manual offboarding process.

Step 5 — Generate the Audit Trail

An automated offboarding workflow that doesn’t produce documentation is an incomplete workflow. The audit trail is your proof of compliance — for SOC 2, for HR records, and for any legal dispute that surfaces later.

At the end of every offboarding run, Make.com should generate a timestamped record that includes:

• Employee name and ID
• Termination date and type
• Timestamp of every action taken, with the system it affected
• Name of the confirming HR manager
• Any manual escalations triggered and their resolution
• Device return status
• DLP scan results summary

Write this record to a secure, append-only log — a dedicated Airtable base, a Google Sheet with restricted edit access, or a compliance platform. Send a summary to HR, IT, and Legal via automated notification. Retain for seven years minimum, or per your legal counsel’s guidance.

Step 6 — Build the Involuntary Termination Branch

Involuntary terminations are higher risk and require a different sequence. Build this as a separate branch in Make.com, triggered by the termination type field in the HRIS payload.

Key differences from voluntary offboarding:

• No advance notice: The workflow fires at the moment of termination, not days before. Account lockout happens immediately — before the employee is informed, not after.
• Physical access revoked immediately: Badge deactivation and building access removal should be API calls in this branch, firing in the same sequence as the IdP suspension.
• Device wipe fires same day: Don’t queue it for return logistics. Send the wipe command and arrange device recovery separately.
• Legal hold is mandatory: Treat the litigation hold as a required step, not optional.
• Manager notification is pre-staged: The manager’s notification should arrive at the same time as the action, not after. They need to be in the room when the employee is informed.

The involuntary branch isn’t just about speed — it’s about sequence. The order of operations in an involuntary termination has legal implications. Run this past employment counsel before you go live.

What This Looks Like in Practice

A mid-market manufacturer using Make.com built this workflow after a voluntary departure where a sales rep downloaded the full customer list the day before their last day. The data was gone before IT knew to look.

After building the automated offboarding workflow, their sequence runs like this: HR confirms termination in the HRIS → Make.com webhook fires within 60 seconds → IdP account suspended, active sessions revoked, email forwarded, and DLP scan queued → all within 90 seconds of HR hitting submit. Device wipe command fires at 5 PM on the last day for voluntary departures, immediately for involuntary. Audit log is in Airtable with a summary emailed to HR, IT, and Legal by the time the employee’s badge is deactivated.

The total build time was 52 hours across two sprints. The workflow has run 34 times without a missed step.

The Most Common Mistakes in Automated Offboarding

Automating before the access audit is complete. The workflow can only touch systems you’ve mapped. Unknown systems stay open. Do the registry work first.

Skipping the confirmation gate. One mis-coded leave of absence going through the full offboarding workflow creates a support disaster and legal exposure. The gate is not optional.

Treating SSO cascade as complete coverage. SSO covers federated applications. It does nothing for tools accessed with saved passwords, personal API tokens, or credentials shared informally between team members.

No branch for involuntary terminations. A single workflow that handles all terminations the same way is wrong. The timing, sequence, and legal requirements are materially different. Build the branch.

Generating no audit trail. Without documentation, the automation didn’t happen in any way that matters to a compliance auditor or an employment attorney.

How This Fits the Larger Operations Picture

Automated offboarding security is one layer of a broader operations architecture. The same Make.com infrastructure that runs your offboarding workflow can handle onboarding, role changes, contractor lifecycle, and compliance reporting — built on the same trigger-and-action logic, the same audit trail framework, and the same error handling patterns.

The OpsMesh™ framework structures how these workflows connect across HR, IT, Finance, and Legal. Offboarding built in isolation breaks when a team member changes roles, a system is retired, or a compliance requirement shifts. Built inside OpsMesh, it inherits the architecture that keeps everything synchronized.

If you’re deciding whether to build this internally or bring in outside help, this breakdown of DIY automation vs. hiring a Make partner covers the decision criteria honestly.

The access gap is a solvable problem. The tools exist, the workflow logic is straightforward, and the cost of not solving it shows up eventually — in a breach, a compliance finding, or a termination that didn’t go cleanly. Close the gap before it costs you.