How to Automate Offboarding and Access Removal Safely

The day someone leaves is the day your access controls get tested. Manual checklists work fine until a resignation lands on a Friday afternoon, the IT lead is on holiday, and a former engineer still has a live session in your production dashboard three weeks later. When you automate offboarding, you replace a checklist that depends on someone remembering with a run that either completed or failed loudly, with a timestamp next to every account it touched.

This guide shows how to build that in Skopx, where workflows are created by describing them in chat in plain English. It also covers the part most automation advice skips: which offboarding actions should never fire automatically, and how to route those to a person instead.

What manual offboarding actually costs teams

The cost is rarely one dramatic breach. It is a slow leak made of small failures:

• Orphaned SaaS seats. Nobody cancels the Figma, Notion, Datadog, and Zoom licenses because nobody owns the list. You keep paying per seat for people who left last quarter.
• Session survival. Suspending an account is not the same as killing active sessions and refresh tokens. Mobile apps in particular can stay signed in long after the directory says the user is gone.
• Shadow access. Personal API keys, shared service accounts, third party vendor portals, and repositories where access was granted directly rather than through a group.
• Knowledge loss. Documents, boards, and recurring meetings owned by a person who no longer exists in your directory. Ownership transfer is fiddly and almost always gets deferred.
• Audit pain. When someone asks "prove that access for this person was removed within 24 hours," a Slack thread is not evidence. A run record is.

Every one of those has the same root cause. The offboarding checklist lives in a document, and documents do not execute.

Why teams automate offboarding badly

The common failure mode is building a workflow that deletes things. It fires on a termination event and starts removing accounts, wiping mailboxes, and reassigning files with no human anywhere in the chain. Then a coordinator marks the wrong person as terminated in the HRIS, or a contract renewal is recorded as an end date, and the automation cheerfully locks out an employee who is still working.

The safer design separates two categories:

1. Containment actions, which are reversible and urgent. Suspending an identity provider account, revoking sessions, disabling API tokens. If you do these to the wrong person by mistake, you undo them in a minute and apologise.
2. Destructive or judgement actions, which are irreversible or need context. Deleting mailboxes, transferring document ownership, final pay adjustments, revoking a customer facing account, deciding whether a departure needs a security review.

Automate the first category. For the second, the workflow prepares the work and notifies a named human who then acts. Skopx has no human approval step, and that constraint pushes you toward the right architecture rather than away from it: instead of a workflow that pauses mid run waiting for a click, you build a workflow that finishes fast, does only the safe part, and hands a complete, pre filled brief to the person who owns the decision.

The workflow design

Start with the basic version. One trigger, a lookup, containment, a log, and a handoff.

Basic offboarding and access removal

HRIS termination webhook

Look up employee

Suspend identity account

Revoke SaaS seats

Append offboarding log

Post handoff checklist

Three trigger options exist in Skopx, and offboarding usually wants two of them working together:

• Webhook. Your HRIS or ticketing tool posts to a unique URL protected by a per workflow secret the moment a termination is recorded. This is the fast path, and it is what you want for same day departures.
• Schedule. A daily run in your chosen timezone that reads the HRIS for anyone whose last working day is today or already past, and catches anything the webhook missed. Schedules can run as often as every 15 minutes, hourly, daily, or weekly.
• Manual. For the messy real world case where a manager walks over and says "she left an hour ago, do it now."

Run both the webhook and the daily sweep. The webhook gives you speed, the schedule gives you a safety net, and the log makes duplicates obvious.

What to automate versus what stays human

The rule of thumb: if undoing the action takes longer than a coffee, a human does it.

How to automate offboarding in Skopx step by step

You do not assemble this on a canvas. You describe it in chat and Skopx builds the workflow, then you open it and check each step.

Step 1: connect the tools first. Go to your workspace and connect the accounts this workflow needs. For a typical setup that means your HRIS, your identity provider, Slack, Google Workspace, and whichever seat based tools you pay for. Skopx connects to nearly 1,000 business tools, so the constraint is usually which admin credentials you are willing to grant, not whether the integration exists. Connect with an admin service account, not a personal login, so the workflow does not break when the person who built it changes roles.

Step 2: describe the workflow in one sentence. Open chat and say something close to this:

When the offboarding webhook fires, look up the employee in our HRIS by their work email, suspend their Google Workspace account and revoke all active sessions, remove them from every Okta group, revoke their Slack, Notion, and Figma seats, collect the list of Drive files and calendars they own without changing anything, append a row to the "Offboarding log" sheet with the person, their last day, the timestamp, and the exact response from every tool, then post a message to #people-ops with that summary, the file ownership list, and a checklist of the manual steps the manager still needs to complete.

Note what that sentence does not say. It never says delete, never says transfer, never says notify the customer. It contains, records, and hands off.

Step 3: check the expressions. Skopx wires data between steps with expressions like {{ trigger.employee_email }} and {{ steps.lookup.output.manager_slack_id }}. Open the workflow after it is built and confirm that the identity suspension step is reading the email from the lookup result rather than straight off the raw webhook payload. The lookup is your sanity check: if the HRIS does not return a matching, currently active employee record, you want the run to stop there.

Step 4: add the condition. A leaver with production database access is not the same as a leaver with a Notion seat. Add an if/else on a field from the lookup, then branch.

Offboarding with a privileged access branch

privilegedstandard

HRIS termination webhook

Look up employee

Privileged access?

Suspend, page security

Suspend and revoke

Draft manager handoff

Post for human action

Conditions in Skopx compare fields with operators like equals, contains, greater_than, and is_empty. A department that contains "Engineering", a role field that equals "Admin", or a group membership list that contains "prod-access" are all workable tests. Keep the test on a field your HRIS actually populates reliably, otherwise the branch is decorative.

Step 5: use an AI step for the handoff brief, not for the decisions. The AI step is good at turning a pile of raw API responses into a readable checklist addressed to a specific manager. It should not be deciding who gets access revoked. AI steps run on your own provider key with zero markup, so you attach your key in settings before the workflow can use them.

Step 6: test with a fake leaver. Create a test account in your directory, run the workflow manually against it, and read every step output. Then restore the account. Do not let the first real run be the first run.

Workflows in Skopx are acyclic and capped at 20 steps, which is a useful forcing function here. If your offboarding needs 40 actions, split it: one workflow for containment, a second for licence reclamation, a third for the manager handoff. Smaller workflows fail in smaller, more diagnosable ways.

How to tell it is working

Every run records each step's real output, how long it took, and the exact error text when something breaks. That gives you four signals worth checking weekly:

The offboarding log sheet is the artefact that matters most. When someone asks whether access was removed for a specific person on a specific date, you point at a row and at the run record behind it. That is a materially different conversation from searching Slack.

One honest note on schedules: if your daily sweep is missed by more than a two hour grace window, Skopx records it as failed rather than firing it late. That is deliberate, because a stale offboarding sweep running at an unpredictable hour is worse than a visible failure you can retry.

Common mistakes

Suspending without revoking sessions. A suspended account with a live refresh token is still an open door on some platforms. Make session revocation an explicit step, not an assumption.

Triggering on the wrong HRIS field. "Status changed to inactive" catches leave of absence and contract pauses too. Trigger on the termination event specifically, and re check the last working day in the lookup step before anything gets suspended.

Letting the workflow delete. Deletion is the one action you cannot undo at 11pm on a Friday. Collect, list, notify, and let a human press the button.

Sending the handoff to a channel nobody owns. Post to a channel with a named owner and mention the specific manager. A message to #general is a message to nobody.

Skipping the vendor tools. The tools outside SSO are exactly the ones that keep charging you. Add every seat based tool you pay for to the revoke list, even the small ones.

Building offboarding without building onboarding. The two workflows share the same tool list and the same group mappings. Teams that build employee onboarding first have already done half the work here, because they know exactly which access gets granted and can mirror it in reverse.

Frequently asked questions

Can Skopx automate offboarding without deleting anything?

Yes, and that is the recommended design. Suspension, session revocation, group removal, and seat reclamation are all reversible. Deletion, mailbox archiving, and ownership transfer are prepared as a checklist and posted to a human who completes them. Skopx has no human approval step, so the pattern is always "finish the safe part, hand over the rest" rather than pausing a run mid flight.

What triggers offboarding if our HRIS cannot send webhooks?

Use a schedule. A daily run in your timezone reads the HRIS for anyone whose last working day has passed and processes them. It is slower than a webhook by up to a day, so pair it with the manual trigger that a people ops coordinator can fire the moment someone resigns.

How do we handle a departure that needs security escalation?

Branch on it. Add an if/else that checks whether the person held privileged access, and on the privileged path have the workflow suspend immediately and post a high visibility alert that mentions the security on call person by name. The workflow contains the account and raises the flag. The investigation is human work.

What does this cost to run?

Skopx is $5 per month for Solo, $16 per seat per month for Team, and $5,000 per month for Enterprise, and every plan bills from day one. AI steps bill to your own provider key with zero markup, so you pay your model provider directly for exactly what those steps consume.

Will auditors accept the run records as evidence?

Run records give you a per step, timestamped account of what executed, what each tool returned, and what failed, which is the kind of artefact access review questions are usually asking for. Skopx operates with SOC 2 controls in place. Talk to your own auditor about what their programme requires, and keep the offboarding log sheet as the human readable index into the runs.

Where to go next

Offboarding is one half of a pair. The same tool inventory and group mappings power onboarding across every tool, and the same HRIS connection powers time off tracking and coverage alerts. Build one, and the next two get considerably faster.

Start by connecting your HRIS and identity provider, then describe the basic version in chat on the workflows page. Run it against a test account, read the step outputs, and only then point it at the real termination feed.