Ghost accounts — active credentials belonging to former employees — exist because offboarding runs on manual IT tickets instead of automatic triggers. A Make.com workflow that fires the moment your HRIS logs a departure disables the SSO session, revokes non-federated app access, and closes every door before the exit interview ends.

This post is the operational companion to our automated offboarding ROI framework. That post makes the strategic case. This one gives you the exact sequence — trigger, kill chain, exception handling, and confirmation audit — to eliminate ghost accounts through a Make.com deprovisioning workflow that runs without a ticket, a Slack message, or an IT email.

Before You Build: Prerequisites, Tools, and Risks

A deprovisioning workflow is only as strong as the access inventory it runs against. Before you configure a single Make.com scenario, confirm these five things are in place.

• A complete application inventory. Every system that holds an employee credential — SSO-federated apps, shadow SaaS, cloud storage, VPN, code repositories, physical access systems — must be documented. Any gap in this list becomes a ghost account.
• A single identity provider or SSO platform. Azure AD, Okta, Google Workspace, or equivalent. This is the master kill switch for every federated app. Without it, you’re revoking access one system at a time — which is exactly the problem you’re trying to solve.
• A direct HRIS-to-IdP integration. The trigger must come from the authoritative HR system of record — not a Slack message, not an email to IT, not a manager updating a spreadsheet.
• Make.com with API access to your SaaS stack. Make.com handles multi-system orchestration natively. You need HTTP modules or native connectors for each non-SSO app in your inventory.
• A defined exception and reversal process. Terminations get entered in error. The workflow must disable, not immediately delete, and include a documented re-provisioning path for reversals within 30 days.

Time investment: Two to four weeks for a mid-market organization with 10–30 integrated systems. Longer if application discovery is incomplete.

Primary risk: Over-automation without an exception gate. A workflow that disables access for a contractor whose status updated incorrectly disrupts live projects. Build a 15–30 minute approval hold between trigger and execution on all contractor and temp records.

The security risks of manual offboarding are not edge cases — ghost accounts, missed SaaS revocations, and delayed IT tickets are the default outcome of ticket-driven processes. Automation is the only structural fix. If you want to validate your process gaps before building anything, the OpsMap™ audit framework is the right starting point.

Step 1 — Inventory Every Access Point Before You Build

You cannot automate deprovisioning against systems you don’t know exist. Step one is a complete access inventory — not just the IT-approved app list, but every system where an employee credential has ever been created.

Pull from three sources in parallel:

1. Your SSO/IdP logs. Export all applications federated through your identity provider. This is your baseline. Every app on this list gets covered by Step 3 automatically.
2. Expense reports and corporate card transactions. Filter for SaaS vendors. Any recurring SaaS charge absent from your SSO list is a shadow app with unmanaged credentials — these require individual API revocations in Make.com.
3. Department head attestation. Send a structured questionnaire to each manager: list every tool your team uses that requires a login. Cross-reference against the SSO export and the expense data. Everything that appears only here goes into your non-SSO revocation queue.

Output of this step: a spreadsheet with every app, its access type (SSO-federated vs. direct login), the API or admin method for revoking access, and the owner responsible for confirming revocation. This spreadsheet drives the Make.com scenario logic in Steps 3 and 4.

Step 2 — Set Up the HRIS Trigger in Make.com

The termination event in your HRIS is the only valid trigger for a deprovisioning workflow. Everything else — a manager notification, an IT ticket, an HR email — introduces lag and dependency on human follow-through.

In Make.com, configure a webhook or polling trigger on your HRIS that fires when an employee record transitions to a termination status. The payload must include:

• Employee ID (used to look up the IdP account)
• Email address (the primary identity key across most SaaS apps)
• Termination date and time
• Employment type (full-time, contractor, temp) — used to route contractor records to the exception gate
• Manager email — for notification and exception approval routing

If your HRIS supports native Make.com connectors (BambooHR, Workday, Rippling, Gusto, and others have them), use the native module. If it doesn’t, use a webhook from your HRIS’s automation or API layer. The trigger fires once — the Make.com scenario handles everything downstream.

For contractor records, insert a router immediately after the trigger. Route contractors through a 20-minute delay module and an approval step before the kill chain executes. Full-time terminations proceed directly.

Step 3 — Kill the IdP Session First

The highest-value action in a deprovisioning workflow is the IdP disable. One API call suspends authentication for every SSO-federated application simultaneously. This is the step that prevents a former employee from logging into Salesforce, Slack, Jira, and your cloud storage in the window between their last day and the time IT processes the ticket.

In Make.com, add an HTTP module (or native connector) immediately after the trigger that calls your IdP’s user suspension endpoint:

• Azure AD / Entra ID: PATCH to the Microsoft Graph API, setting accountEnabled: false on the user object.
• Okta: POST to /api/v1/users/{userId}/lifecycle/suspend.
• Google Workspace: PATCH to the Admin SDK Directory API, setting suspended: true.

Configure error handling on this module with a retry (three attempts, 60-second interval). If the IdP call fails after three attempts, route to a Slack alert and a Teamwork task assigned to IT — the workflow escalates rather than silently failing.

Do not delete the IdP account at this stage. Suspension preserves the audit trail, email history, and data ownership. Deletion happens after the retention window defined in your offboarding policy — typically 30 to 90 days, executed as a separate scheduled Make.com scenario.

Step 4 — Revoke Non-SSO Access App by App

SSO handles the federated apps. Everything else requires a direct API call or an admin action inside each platform. This is where your access inventory from Step 1 drives the Make.com scenario structure.

For each non-SSO app in your inventory, add a separate route in Make.com with an HTTP module calling that app’s user deactivation endpoint. Common ones:

• GitHub: DELETE to /orgs/{org}/members/{username} removes org membership. Suspend the user account separately if the account is corporate-owned.
• AWS IAM: Call UpdateLoginProfile to disable console access, then ListAccessKeys + UpdateAccessKey (status: Inactive) to deactivate API keys.
• Dropbox for Business: POST to the Dropbox Business API /team/members/suspend.
• 1Password Business: PATCH to the Connect API to deactivate the user record.
• Any app without an API: Route to a task in Teamwork assigned to the app owner with the employee name, email, and a deadline of one hour. Track completion via a webhook back into Make.com.

Run all non-SSO revocation routes in parallel — Make.com handles concurrent branches. There is no reason to run these sequentially.

For apps that have no API and no admin-assigned owner, escalate immediately. These are the highest-risk ghost account sources in your environment. Address them during the access inventory phase, not during a live termination.

Step 5 — Run the Confirmation Audit

Execution without confirmation is not deprovisioning — it’s hoping. The final step in the Make.com scenario generates a structured confirmation record that documents what ran, what succeeded, and what failed.

After all revocation branches complete, add a Make.com aggregator module that collects the status response from each step. Pass that payload to a confirmation action:

• Create a Teamwork task (or equivalent) titled “Offboarding Confirmation — [Employee Name] — [Date]” with the full status log attached as a note.
• Send an email to HR and IT with the confirmation summary: apps revoked, apps pending manual action, any steps that returned errors.
• Write the confirmation record to Airtable (or your HRIS) with the employee ID, termination timestamp, and revocation status per system. This is your audit trail.

Any app that returned an error or has no automated revocation path must appear explicitly in the confirmation report as “action required.” The person receiving that report owns resolution within a defined SLA — typically four hours for same-day terminations.

Exception Handling and Reversals

Two scenarios break automated deprovisioning workflows if you don’t plan for them in advance.

Incorrect termination entries. An HRIS record gets updated with a termination date in error — a status change, a data entry mistake, a test record that hits production. Your workflow fires. Access gets suspended before anyone catches it.

The fix: build a reversal Make.com scenario that re-enables IdP access, re-activates each non-SSO system, and generates a “reversal confirmed” audit record. Store this scenario alongside the deprovisioning scenario and document the re-provisioning path for IT. Reversals within 30 days should be executable in under 15 minutes.

Leave of absence vs. termination. Some HRIS configurations use the same status field for LOA and termination, or LOA records pass through a termination-adjacent status during processing. Map your HRIS status codes explicitly in Make.com’s router — only the specific codes that represent confirmed termination should trigger the kill chain. LOA records route to a separate, lower-severity flow that disables new authentications without revoking data access.

What This Workflow Eliminates

A Make.com deprovisioning workflow running against a complete access inventory eliminates three failure modes that define manual offboarding:

• Timing gaps. Manual processes take hours to days. Automated workflows execute in minutes. The window where a former employee holds valid credentials collapses from days to zero.
• System blind spots. Shadow apps and non-SSO tools get missed in ticket-based offboarding. A documented access inventory forces every system into the automated revocation chain.
• Audit gaps. Manual processes produce no reliable audit trail. Every automated run produces a timestamped confirmation record tied to the employee ID and the termination event.

This workflow is one component of a broader operational structure. The OpsMesh™ framework connects deprovisioning to onboarding, role change workflows, and access governance into a single orchestrated system — so access management runs as a consistent process, not a one-off response to terminations. If you’re evaluating your current automation gaps before building, start with the seven questions to ask before you automate anything — the same checklist applies here.