# Catch departed employees who still have system access

> Every weekday morning, we cross-check recent departures against your identity system and flag anyone whose access is still switched on.

- Workflow type: agent
- Services: Workday, Okta, Slack
- Categories: Operations, HR & People
- Published: 2026-08-10

## What it does

- Pulls everyone who left the company in the last 30 days, along with their work email and last day.
- Checks each person against your identity system to see whether their account was genuinely switched off.
- For anyone still live, lists exactly which applications and groups they can still reach.
- Posts one ranked alert to your security channel, worst case first, and stays completely quiet on clean days.

## What you'll need

- A Workday account with permission to view worker and termination data
- An Okta administrator login
- A Slack workspace and a security channel to post into
- Optional: an existing terminations report in Workday, if your team already maintains one

## Prompt

Every weekday at 6am, audit for departed employees who still have live access, and report what you find without changing anything.

Start in Workday. Use WQL – Run Query to list workers whose termination date falls within the last 30 days, returning at minimum full name, work email, termination date, manager, and business unit or department. If we already maintain a terminations report in Workday, use Report-as-a-Service – Run Custom Report against that report instead, since it already reflects the filters our HR team cares about. Note that Workday has no dedicated list-terminated-workers REST operation, so WQL is the sanctioned way to query termination dates.

For each terminated worker, look them up in Okta with Retrieve User, using their Workday work email as the login. If that returns nothing, fall back to List Users with a search filter on the profile email address, because a work email in Workday does not always match the Okta login exactly. If there is genuinely no matching Okta account, record that person as clean and move on.

Flag anyone whose Okta account is not fully deprovisioned as of a date later than their termination date. Interpret status like this: ACTIVE, LOCKED_OUT, PASSWORD_EXPIRED, or RECOVERY all mean the account is still live and are the highest concern. SUSPENDED means sign-in is blocked but application assignments and group memberships are still attached, so it is still an outstanding finding, just at lower severity, and say so explicitly in the report. DEPROVISIONED is clean, exclude it.

For each flagged person, gather the blast radius. Use List User App Links to get the applications still assigned to them, and List User Groups to get their group memberships. If a particular application looks especially sensitive and you want to confirm the assignment or see who else is on it, use List Application Users for that specific app.

Rank the findings worst case first. Score each person on two factors: how many days have elapsed since their termination date, and how sensitive the applications they can still reach are. Treat these as high sensitivity: finance and payroll systems, cloud infrastructure and code repositories, administrative consoles, CRM and customer data systems, email and file storage, and security tooling. Group names that imply elevated privilege, anything containing admin, superuser, prod, or owner, should also raise severity.

Post one prioritized alert to our security Slack channel using Send a Message. Lead with a one-line summary giving the number of people still holding access out of the number of departures checked. Then list each person worst case first with: full name, work email, termination date, days elapsed, current Okta status, the applications still assigned with the sensitive ones called out, group memberships, and the Okta user ID so a human can go straight to the account. Include enough detail that a reviewer can act without opening Workday themselves.

Do not deactivate, suspend, or unassign anything. This workflow is report-only by design. Never call Deactivate User, Suspend User, or Unassign User from Application. Automatically revoking access on an HRIS data mismatch is how people get locked out on their first day back from leave, and security teams want to review before revoking.

Stay silent on clean days. If every terminated worker is either fully deprovisioned or has no Okta account at all, post nothing. The channel should only light up when something is actually outstanding, otherwise the alert loses its signal value.

Watch for false positives rather than suppressing them. Rehires, workers holding a second active job, and contingent-to-permanent conversions all produce a termination record alongside legitimate ongoing access. If Workday shows a later active record for the same person, keep them in the report but note the likely explanation inline so the reviewer can dismiss it quickly.

## How to customize

- Change the schedule or the lookback window, for example a 60 day window or a single weekly run on Monday.
- Set which applications count as high sensitivity so the ranking reflects your own risk model.
- Choose which channel it posts to, and whether to tag the person who owns access reviews.

## Example output

Offboarding access audit: 2 of 7 recent departures still have live access

1. Dana Whitfield (dana.whitfield@acme.com) HIGH
Terminated 24 days ago (2026-07-16). Okta status: ACTIVE.
Still assigned: AWS Console, GitHub, NetSuite, Salesforce, Google Workspace
Groups: engineering-all, aws-prod-admins, okta-superusers
Okta ID: 00u1a2b3c4d5e6f7g8h9

2. Marcus Ellery (marcus.ellery@acme.com) MEDIUM
Terminated 9 days ago (2026-07-31). Okta status: SUSPENDED (sign-in blocked, but app assignments and groups still attached).
Still assigned: Salesforce, Zendesk, Confluence
Groups: sales-emea, crm-users
Okta ID: 00u9z8y7x6w5v4u3t2s1

5 other departures verified fully deprovisioned. Nothing was changed automatically.

## FAQ

### Will this deactivate anyone automatically?

No. It is deliberately read only. It reports what it finds and leaves the decision to a person. Automatically revoking access based on a mismatch in HR data is how someone gets locked out on their first day back from leave, so security teams almost always want to review before anything is switched off.

### What happens on a day when nothing is wrong?

Nothing gets posted. The alert only appears when there is something genuinely outstanding, which is what keeps it worth reading. A channel that lights up every morning with an all clear stops being noticed within a week.

### Do we need to build a terminations report in Workday first?

No. It can query termination dates directly. If your team already maintains a terminations report, it can use that instead, which is often the better option because your report already reflects the filters and exclusions your HR team cares about.

### What if someone was rehired after leaving?

Rehires are the most common false alarm in this kind of check. When it spots a later active record for the same person, it flags that inline in the alert rather than silently dropping them, so a reviewer can see why the account is still open.

### Will it still find people whose work email does not match their login?

Yes. If a direct lookup by work email comes back empty, it searches by email address across the directory before concluding there is no account, since the two do not always match exactly.

Use this prompt in General Input: https://www.generalinput.com/prompts/catch-departed-employees-who-still-have-system-access