okta scim deprovisioning failed user stuck limbo

okta scim deprovisioning failed user stuck limbo

TL;DR

Open the app's provisioning Tasks tab in Okta and read the exact failure on the stuck task. Fix the underlying cause in the target app (usually the user was deleted there first, or an identifier mismatch makes the SCIM call 404), then retry the task from Okta. If the retry keeps failing, complete the task manually only after confirming the user is actually deactivated in the target app.

okta scim deprovisioning failed user stuck limbo

Use this when

• An Okta provisioning task for a user deactivation shows failed and keeps retrying
• The user is deprovisioned in Okta but still active in the target app
• The SCIM deprovision call returns 404 or 400 in the task error detail
• A batch offboarding left some users in a half-deprovisioned state

Not for this skill when

• The user was never assigned to the app (nothing to deprovision)
• Deprovisioning was done manually in the target app only (reconcile instead)
• The app has no SCIM connector and uses a different provisioning mechanism

Steps

Step 1: Find the failed task

In the Okta Admin Console go to Applications, open the app, then Provisioning, then the Tasks tab. Filter for the user and open the failed deactivation task to read the exact error message and timestamp. Expected: you can quote the failure, e.g. a 404 from the target SCIM endpoint, instead of guessing.

Step 2: Compare lifecycle state on both sides

Check the user's status in Okta (Directory, People) and in the target app's own admin or user list. Note exactly which side thinks the user is active. Expected: you know whether Okta is ahead of the app or behind it.

Step 3: Fix the target side first

If the user still exists in the target app, deactivate or delete them there directly, or fix whatever the error named (duplicate email, missing manager reference). If the user was already deleted in the target app, that 404 is actually the desired end state. Expected: the target app's user list reflects the intended final state.

Step 4: Retry the task from Okta

Back in the Tasks tab, select the failed task and retry it. Okta replays the SCIM deactivation against the now-correct target state. Expected: the task flips to success and the user's app assignment clears.

Step 5: Close out unretryable tasks deliberately

If the task cannot succeed because the target state is already correct (user gone), mark it complete manually and document why. Never mark tasks complete to hide a real failure. Expected: zero failed tasks remain, each with a documented resolution.

Step 6: Verify end to end

Confirm the user cannot log in to the target app and that Okta shows the deprovisioning complete. For offboarding batches, spot check a sample. Expected: login attempts fail and both systems agree on the status.

Tool compatibility

Okta Identity Engine with Lifecycle Management; SCIM 2.0 (RFC 7643/7644) target apps; Okta Admin Console provisioning Tasks view.

Variant phrasings

Variant 1

okta scim deprovision task failed user still active in app

Variant 2

scim user deactivation 404 okta provisioning retry

Variant 3

okta offboarding stuck user not deprovisioned in target application

Why it happens

SCIM deprovisioning usually maps to a PATCH that sets active=false or a DELETE against the target user resource. When the target-side user was deleted by hand, renamed, or keyed on a different identifier (username vs email), Okta's call 404s and the task fails instead of converging. Okta retries failed tasks on its schedule, so the user sits in limbo: deprovisioned in Okta's directory, live in the app, with the retry loop never resolving on its own. The fix is always to reconcile the target side to the intended end state first, then let Okta replay or close the task, because Okta cannot delete a user record the target app no longer recognizes.

Edge cases / pitfalls

• Apps that soft-delete on deactivation: the SCIM DELETE succeeds but the user can be restored, so verify the app's own deactivated list.
• Group push deprovisions behave differently from app assignments; check which mechanism owns the user before retrying.
• Downstream provisioning (app to app chaining) can re-create the user after you deactivate; check for chained provisioning rules.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y4n77ZkwEVe5Df-0Hp1uIQ