## TL;DR
Work the failing application assignment, not the whole lifecycle event, because deprovisioning succeeds app by app and one stuck assignment blocks the clean record. Open the terminated user, list their remaining app assignments, and open the provisioning or deprovisioning log for the failing app to read its specific error, commonly a user already deleted in the app, a group managed assignment that cannot be removed individually, or a missing admin permission for the connector. Resolve that app state, retry deprovisioning for that app, and repeat until the user shows no active assignments.

```text
Okta lifecycle management deprovisioning failed: app assignment error troubleshooting
```

## Use this when
- A deactivated Okta user still has accounts in one or more downstream applications.
- The lifecycle task shows an error on a specific application assignment.
- Terminated users accumulate in an app that the review then flags.

## Not for this skill when
- The user should never have been deactivated. Restore the Okta user through the HR dispute process instead.
- The app is not managed by Okta provisioning. Deprovision it in the app and record the manual step.

## Steps
1. Open the deactivated user in Okta and list every remaining application assignment with its assignment type, individual or group based. Verify: each remaining assignment is listed with its type.
2. Open the Okta provisioning task or system log entries for the failing application and copy the exact deprovisioning error and its timestamp. Verify: the app specific error is recorded verbatim.
3. Check the target application for the user current state, whether the account exists, is already deleted or is managed by a group the user still belongs to through another path. Verify: the app side state explains the Okta side error.
4. If the assignment is group based, remove the user from the assigning group or exclude them through the lifecycle rule, since individual unassignment cannot override a group grant. Verify: the group path no longer assigns the application to this user.
5. Retry deprovisioning for that application from the Okta provisioning view and confirm the app account is deactivated or deleted as the integration specifies. Verify: the retry succeeds and the app confirms the user is inactive.
6. Repeat the check for every remaining assignment until the user record shows no active application access, including manual apps handled outside provisioning with a ticket reference. Verify: the user shows zero active assignments across all apps.
7. Add the case to the termination checklist review, noting which assignment type caused the block so future offboarding checks that app first. Verify: the checklist gains the named app check with this case as the reference.

## Why it happens
Okta deprovisioning is a fan-out of per application jobs with different connectors, permissions and assignment types. A group based assignment cannot be removed by deleting the individual assignment, and an app where the account was already deleted by hand can return an error that stalls the tidy-up even though access is actually gone. Reading the per app log separates real remaining access from bookkeeping noise, which matters because access reviews will flag both until the record is clean.

## Variants and edge cases

### terminated user still has app access after Okta deactivation
The audit phrasing. Check assignment type first; group grants are the most common reason access survives user deactivation.

### Okta deprovisioning task error on one application
The task phrasing. Work that app connector log, not the user lifecycle status, which aggregates every app into one vague state.

### group assigned app cannot be unassigned for leaver
The group phrasing. Remove the group membership or add a leaver exclusion; the individual assignment will follow.

Edge cases to check before closing the review cycle:
- Some apps only suspend on deprovision and delete after a retention period. Record the expected delete date rather than chasing it daily.
- An app admin permission change can break the connector for every leaver. If many users fail on one app, fix the connector credentials or roles.
- Contractors returning seasonally may need suspension, not deletion. Confirm the leaver type before forcing deletes.

Compatibility: Okta Lifecycle Management and provisioning connectors, Okta system log, group based application assignments.

## Provenance

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