Automated access revocation removes every credential within minutes of a termination event — not hours or days. An HRIS trigger fires a Make.com scenario, your IAM platform revokes every connected account, and a timestamped audit log captures the proof. Every departure, planned or emergency, executes the same way.

Access revocation is the highest-stakes task in any offboarding workflow — and the one most likely to fail when it runs on manual checklists. A single missed CRM account, a dormant VPN credential, or an unrevoked repository permission is all a former employee or external attacker needs. This guide walks you through the exact sequence to automate access revocation end-to-end, from HRIS trigger to immutable audit log.

Before You Build: Prerequisites and Risk Assessment

Automated access revocation is a workflow integration project, not a software purchase. Confirm these elements are in place before writing a single Make.com scenario step.

Required Systems

• HRIS or HCM platform — The system of record for employee status. Termination events here are your automation trigger.
• Identity and Access Management (IAM) platform — Manages identities and enforces access policies across connected systems. Organizations with mature IAM programs significantly reduce their mean time to deprovision compared to those running manual processes.
• Make.com as your automation layer — The integration middleware that listens for the HRIS termination event and calls the IAM API. This is where your workflow logic lives.
• System inventory — A documented list of every application, SaaS tool, network share, and physical access system where employees hold credentials. If this list does not exist, create it before building the workflow.
• Audit log destination — A SIEM, data warehouse, or compliance platform where every deprovisioning action is written with a timestamp and actor ID.

Time Estimate

For organizations with a functioning IAM platform and an accessible HRIS API, initial workflow setup runs 2–4 weeks. Organizations without a centralized IAM platform should budget 60–90 days for the IAM implementation before automation layers on top.

Primary Risk

The most common implementation risk is an incomplete system inventory. If a SaaS tool is not in your inventory, it will not be in your automation workflow, and access will not be revoked automatically. Shadow IT — tools provisioned by departments outside IT oversight — is the leading source of orphaned accounts. Audit your application landscape before you go live.

Step 1: Audit Your Access Landscape and Close Shadow IT Gaps

You cannot automate revocation for systems you do not know exist. The first step is a complete access inventory across every environment where your employees operate.

Run an access audit that pulls from three sources: your IAM platform’s current user roster, your finance team’s SaaS subscription list (any tool with a recurring charge has users), and a department-by-department survey asking managers to list every tool their team uses. Cross-reference all three lists. The gaps — tools that appear in one source but not another — are your shadow IT exposure.

For each system identified, document:

• System name and type (SaaS, on-premise, cloud IaaS)
• Access control method (SSO-connected, local credentials, API key, shared login)
• Data sensitivity classification (public, internal, confidential, regulated)
• Current deprovisioning method (automated via IAM, manual IT ticket, self-service admin, unknown)
• System owner — the person responsible for verifying revocation is complete

SSO-connected systems are the easiest to handle: disable the identity in your IAM platform and access is cut off everywhere simultaneously. Non-SSO systems require individual API calls or manual steps, which is where most orphaned accounts hide.

Step 2: Configure the HRIS Termination Trigger

The trigger is the most important design decision in the entire workflow. Get it wrong and your automation fires late, fires twice, or does not fire at all.

The termination event in your HRIS is the source of truth. When HR marks an employee as terminated in the system of record, that status change fires the Make.com scenario. Do not rely on calendar reminders, Slack messages, or IT tickets as your trigger — all of these introduce human delay and create a gap between the last day worked and the moment access is revoked.

Design the trigger to capture:

• Employee ID (stable identifier across all systems)
• Termination date and time
• Termination type (voluntary, involuntary, end of contract, emergency)
• Manager and HR contact for exception handling

Termination type determines the scenario’s execution path. A voluntary departure with two weeks’ notice runs a standard sequence. An involuntary termination or a for-cause separation triggers an accelerated path — SSO disabled within minutes, all active sessions terminated, and notification sent to the security team before the employee leaves the building.

Before building this trigger, run an OpsMap™ audit to confirm every downstream system is mapped and owned. Skipping this step is the single most common reason revocation workflows have blind spots at launch.

Step 3: Build the Make.com Revocation Scenario

The Make.com scenario translates the HRIS termination event into actions across every system on your inventory list. The architecture follows a consistent pattern regardless of how many systems you are revoking access from.

Scenario Architecture

The scenario opens with a webhook or scheduled watch module that listens for termination events from your HRIS. From there, a router splits execution into two paths: SSO-connected systems and non-SSO systems.

SSO-connected path: A single API call to your IAM platform disables the user identity. Because your SaaS tools authenticate through that identity, this one action cuts access to every SSO-connected system simultaneously. This path executes first — under 60 seconds for most IAM platforms.

Non-SSO path: Each non-SSO system requires its own API call or module. These run in parallel where the system supports it, sequentially where they do not. Common non-SSO systems include legacy applications with local credential stores, shared admin accounts in tools that do not support per-user provisioning, and physical access systems controlling building entry.

Error Handling

Every API call in the scenario needs an error handler. The standard configuration: three retry attempts at 60-second intervals before the route breaks and sends an alert. If a revocation fails after retries, the scenario writes the failure to the audit log, notifies the IT owner listed for that system, and continues processing remaining systems. A revocation failure in one system does not halt revocation across others.

What Not to Skip

• Active session termination — disabling a user account does not always kill sessions already in progress. Force-logout separately for any system where this applies.
• API keys and service accounts tied to the departing employee — these outlive the user account by months or years if not explicitly revoked.
• Shared credentials — if the employee had access to a shared admin account, rotate that credential as part of the offboarding sequence.

The error-handling architecture described here transfers directly to any high-stakes Make.com workflow. See how the same patterns hold in production in the case study on how David eliminated daily CRM entry with a single Make scenario — the retry logic and failure-notification design are nearly identical.

Step 4: Write Every Action to an Immutable Audit Log

Every revocation action the scenario takes — successful or failed — writes a structured record to your audit log destination. This is not optional. It is the evidence layer that makes automated offboarding defensible in an audit, a lawsuit, or a security incident investigation.

Each log entry captures:

• Timestamp (UTC)
• Employee ID and name
• System affected
• Action taken (account disabled, session terminated, credential rotated)
• Result (success, failure, partial)
• Make.com scenario execution URL — for direct trace-back to the run
• Actor ID (the scenario’s service account, not a human)

Write logs to a destination that cannot be modified after the fact — a SIEM, a compliance platform, or a write-once object storage bucket. Logs stored only in Make.com’s execution history are insufficient: execution history has retention limits and is not designed for compliance retrieval.

For regulated industries — healthcare, finance, government contractors — your log format and retention period are defined by compliance requirements. Confirm those requirements before finalizing the log schema.

Step 5: Test Emergency Offboarding Before You Need It

The standard offboarding workflow is straightforward to test — run a termination event against a test account and verify each system. The emergency offboarding path is harder to test and more likely to fail under pressure.

Run a tabletop exercise that simulates an immediate termination: an employee is separated for cause at 2:00 PM on a Friday. Who initiates the HRIS status change? Who verifies the SSO disable executed? Who checks the non-SSO system list? Who receives the security alert? What happens if the IAM platform is unavailable?

The tabletop exposes gaps the scenario test does not: organizational gaps (who does what), communication gaps (who knows what happened), and dependency gaps (what breaks if a system is down). Document the emergency procedure as a one-page runbook that any HR or IT team member can execute without deep automation knowledge. The Make.com scenario handles the technical execution; the runbook handles the human coordination layer.

Step 6: Maintain the System Inventory as It Changes

An access revocation workflow is only as current as your system inventory. New SaaS tools get added every quarter. Old ones get retired. Integrations change. A six-month-old inventory means six months of blind spots in your automation.

Build a quarterly review process: finance pulls the current subscription list, IT cross-references against the inventory, and any new system gets evaluated for IAM connection or manual procedure. Make.com can automate the data pull and comparison — the human decision is whether a new system warrants an automated revocation path or a documented manual step. See 7 questions to ask before you automate anything for the evaluation framework that applies here.

The organizational discipline to maintain this inventory is harder than the technical build. Treat it as a compliance asset, not an IT project — it belongs in your security documentation alongside your data classification policy and incident response plan.

Frequently Asked Questions

How fast does automated access revocation execute compared to manual offboarding?

For SSO-connected systems, access is revoked within 60 seconds of the HRIS termination event firing the Make.com scenario. Manual offboarding processes average 2–5 business days to complete across all systems, according to identity security research. The gap is not incremental — it is the difference between a credential that exists for minutes versus days after separation.

What happens when the Make.com scenario hits a system with no API?

Non-API systems — legacy applications, physical access systems, tools with only admin-panel access — cannot be revoked by the automated scenario. The scenario handles two things for these: it flags them in the audit log as requiring manual action, and it sends a notification to the designated system owner with the employee details and a completion deadline. The manual step is tracked; it is not ignored.

Does Make.com handle the volume of API calls required for large-scale offboarding events?

Yes. Make.com’s architecture handles parallel execution across multiple systems within a single scenario run. For mass offboarding events — layoffs, restructures — scenarios trigger in bulk from a data store or spreadsheet input, processing each termination record sequentially while executing system revocations in parallel within each run.

Who owns the audit log in a compliance audit?

The audit log destination system owner — IT security or compliance — owns the log for audit purposes. Make.com execution history supports operational trace-back, but the authoritative compliance record lives in the SIEM or compliance platform where logs are written. Establish this ownership before you go live so there is no ambiguity when an auditor asks for documentation.

How does automated revocation handle contractor and vendor access?

Contractors and vendors require a separate identity lifecycle process. Most HRIS platforms manage full-time employee records; contractor records are frequently maintained in a separate system or not at all. Map contractor identity sources separately, confirm they have a termination event that serves as a trigger, and build a parallel workflow or extend the existing one to handle non-employee identities. Do not assume the employee workflow covers contractors by default.