Automated employee offboarding sweep from SuccessFactors

Every morning at 6am in our company timezone, run a deterministic offboarding sweep that cuts off access for employees whose termination has already taken effect. Use a cron trigger. SuccessFactors does not emit outgoing webhooks for termination events, so a daily bounded query is the correct shape. Every step here is a known lookup or a known create, so build this as code with no judgement calls or drafting.

Step 1, find the leavers. Query SAP SuccessFactors with List Employment Terminations (EmpEmploymentTermination) for termination records whose effective date is today or earlier. This entity carries both the termination date and the termination reason, which I need later. Filter out anything dated in the future and never act on it. This is the single most important rule in the workflow: an employee whose last working day has not yet arrived must not be touched under any circumstances.

Step 2, resolve each leaver's identity. For each terminated userId, get the person's work email using List Email Addresses (PerEmail), selecting the business email type, and get their display name using List Persons (PerPerson). The work email is what links the HR record to the identity system.

Step 3, skip anyone already processed. Before taking any action, look the person up in Okta with Retrieve User using their work email as the login. If that user is already SUSPENDED or DEPROVISIONED, treat the termination as already processed and skip them completely: no suspension call, no Jira ticket, no Slack line. This is how the sweep stays idempotent when it runs again the next morning, without needing to write a processed flag back to the HRIS. If the lookup returns no user at all, do not stop; record that no account was found and continue to the ticketing and Slack steps so the leaver is still visible to IT.

Step 4, cut access first. Call Suspend User in Okta before anything else runs for that person. Suspend blocks sign-in immediately while keeping app assignments and group memberships intact, which makes it reversible if the HR record turns out to be wrong and leaves the access footprint available for review. Ordering matters: the identity step must complete before the slower ticketing and messaging steps, so a departing employee loses access in seconds rather than waiting behind ticket creation. If an organisation's policy is full deprovisioning instead, Deactivate User is the alternative, which revokes sessions and moves the user to DEPROVISIONED. Make the choice between Suspend and Deactivate an easy one-line change.

Step 5, raise the IT ticket. Use Create Issue in Jira to open one asset recovery and access review ticket per leaver in our IT project, assigned to the IT queue. The summary should name the person, and the description must carry the termination reason and the last working day taken straight from the SuccessFactors record, along with their work email, whether the account was suspended successfully, and a checklist covering laptop and equipment recovery plus a review of any remaining application access.

Step 6, notify IT. Use Send a Message in Slack to post to our private #it-offboarding channel. Post one concise summary line per leaver containing the name, the last working day, the termination reason, the suspension result, and a link to the Jira ticket. The whole point is that IT gets the context they need without opening the HRIS. If several people are processed in the same run, post one line each rather than a single merged blob. If there are no eligible leavers, post nothing and finish quietly.

Error handling: if the Okta suspension fails for someone, do not abort the run. Still create the Jira ticket and still post the Slack line, and flag the failure loudly in both so a human picks it up. Process each leaver independently so one bad record cannot block the rest of the sweep.