## TL;DR
Open the app's Provisioning > Integration logs in Okta and find the failed deprovisioning task and its error. Fix the connector issue (usually expired API credentials or a missing required attribute), then retry the task. Verify the user is actually gone from the app, not just deactivated in Okta.

## The error
```text
(Offboarded user still shows as active in the downstream app days after Okta deactivation.)
```

## Steps
1. Okta Admin > Applications > the app > Provisioning > Integration logs. Expected: the deprovision task with an error (e.g. "invalid credentials" or "user not found").
2. For credential errors: check the app's API token or OAuth connection in the Provisioning > Integration tab. Expected: valid. Tokens expire silently and break all provisioning.
3. For "user not found" errors: the app-side account may have been renamed or manually deleted. Expected: identified. Clean up the orphan and mark the task complete.
4. Retry the failed task from the log. Expected: success. Then confirm in the app itself that the user is deactivated or deleted per the deprovisioning profile.
5. Check whether OTHER users are stuck in the same app. Expected: none. A systemic connector failure affects everyone; fix it once.

## When to use
- Deprovisioned users retain app access
- Provisioning log shows failed deprovision tasks

## When not to use
- Provisioning (granting access) failures
- Okta user deactivation itself failing

## Compatibility
- Okta Lifecycle Management; SCIM or API-based provisioning apps

## Variants
### Deprovisioning profile set to "deactivate" but app needs "delete"
Check the app's deprovisioning settings. Some compliance regimes require hard delete, not deactivate.
### Works for new offboardings but old ones are stuck
The connector broke at some point and tasks queued behind it. Clear the backlog after fixing the connector.

## Why it happens
Deprovisioning depends on a working API connection to each app. When the connection breaks, Okta queues failed tasks and the user keeps access indefinitely, which is exactly the compliance risk lifecycle management exists to prevent.

## Edge cases
- Apps without provisioning connectors: deprovisioning is manual; keep a checklist per app.
- Re-hired users: ensure the reactivation path re-provisions cleanly rather than colliding with the old account.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AkH5p5VvelFHRzZcYjmwBw