Terminations and Rehires Collide in HR Lifecycle
An HR-driven Okta lifecycle integration processes 30,000 employees from Workday. Termination events arrive at 17:00 local time. Okta deactivates the user, but 450 Salesforce sessions remain active because Salesforce is configured with long-lived local sessions and the SAML app has no single logout. Another 120 deprovisioning actions fail in the SCIM connector with 429 and 400 errors and are not retried. Rehires within 90 days are common: HR reuses the same email address but issues a new employee number, and the onboarding script tries to create a new Okta user, receiving login already exists. Some rehires then get two Okta profiles, one deactivated with old app assignments and one new with none. You must reduce access after termination, make deprovisioning reliable, and define a rehire process that does not create duplicate identities.
1. What should happen in Okta at termination to reduce access quickly, and what are the limits?
Read the worked answer
For a termination, deactivate the Okta user rather than suspend; suspension is better for leave or investigation because it preserves access for a planned return. Deactivation removes Okta access and app assignments, and you should also revoke the user's Okta sessions through the Sessions API so browser sessions cannot continue. Trigger SCIM deprovisioning to downstream apps and remove app assignments only after deprovisioning succeeds or is queued.
Okta cannot directly kill a local Salesforce session that was created before deactivation. To reduce that window, enable SAML single logout or the vendor's supported logout integration, shorten Salesforce session timeout, and use Universal Logout where supported. Test the actual sequence with one user: deactivate, revoke sessions, confirm SCIM deactivation, then confirm the app rejects new access. The residual risk is app-local sessions, so document it and pair it with app-side timeout controls.
2. How would you make SCIM deprovisioning reliable when some actions fail with 429 or 400?
Read the worked answer
Treat SCIM deprovisioning as an asynchronous workflow with observable state, not a fire-and-forget call. For 429, honor the connector's retry guidance and use backoff with jitter; for 400, classify the error as a data or mapping problem and route it to an operator instead of retrying forever. Make the deprovision operation idempotent by setting active to false or deleting the same external identity, so a retry cannot create side effects.
Monitor Okta System Log events and connector health for failed app user updates, and alert when a termination remains incomplete past a defined SLA. Use a workflow or queue to retry transient failures and to record the final state. Do not remove the app assignment before SCIM has attempted deprovisioning, or you may lose the ability to retry. Keep an audit trail that links the HR termination event, the Okta deactivation, and the app deprovision result.
3. Design a rehire process that avoids duplicate Okta profiles when HR reuses email but issues a new employee number.
Read the worked answer
Match on a stable person identifier, not email. If Workday can supply a person ID that survives rehire, use that as externalId; if only worker IDs are available, store both person ID and worker ID and define which one governs matching. On rehire, search Okta by that identifier and by login before creating anything. If the old profile is deprovisioned, reactivate it, update the login and profile, and then assign apps based on the new role. Do not clone old entitlements automatically.
If the old profile cannot be reactivated, create a new profile only after resolving the login conflict, and link it to the HR person ID so the history is clear. Update the SCIM externalId according to the vendor's matching rules, and test a rehire with a changed email and a rehire with the same email. The key is to make the onboarding script an upsert with explicit conflict resolution, not a blind create that turns a reused email into a second identity.