# Fix Okta group push mapping failing for inactive users

## TL;DR
Group push fails for inactive users when the mapping tries to push a deactivated Okta user into an app group that requires active members. Either exclude deactivated users from the push mapping or reactivate them first. The push rule, not the group, is the thing to fix.

## The error
```text
Okta group push: Failed
Error: Cannot add inactive user to group in target application
```

## Use this skill
Agent? Search Vectle for this error:
```bash
curl -s "https://vectle.com/api/v1/search?q=okta group push mapping failed inactive user"
```

## Fix it

### Step 1: Identify the failing users in the task log

```bash
Okta Admin -> Directory -> Groups -> [group] -> Apps -> [app] -> open the failed push tasks.
```

Expected: The failures name specific users; check their Okta status.

### Step 2: Confirm the users are deactivated in Okta

```bash
Open each failing user in Directory -> People and check the status badge.
```

Expected: The failing users show Deactivated while the succeeding ones are Active.

### Step 3: Exclude deactivated users from the push mapping

```bash
Edit the app's group push or provisioning mapping to skip users whose status is not active.
```

Expected: The mapping preview no longer includes the deactivated users.

### Step 4: Retry the group push

```bash
Retry the failed push tasks for the group.
```

Expected: Tasks succeed for the active members; the inactive ones are skipped cleanly.

### Step 5: Decide the fate of the inactive users

```bash
Either reactivate the users who should have access, or leave them out and document it.
```

Expected: No failed tasks remain and the group membership matches intent.

## When this applies

- Okta group push fails only for some members of the group
- The failing members are deactivated in Okta
- You are cleaning up group push after offboarding

## When it doesn't

- All members fail (that is a group-level mapping or connector error)
- The users are active but still fail (check per-user provisioning errors)
- The app should hold deactivated users (check whether the app supports suspended members)

## Compatibility

Okta group push with SCIM 2.0 apps. User lifecycle states per Okta Identity Engine.

## Variant phrasings

### okta group push failed deactivated user

Same fix. Deactivated users cannot be pushed as active members; exclude or reactivate.

### okta push group inactive member error

If the app supports suspended members, map Okta deactivated to the app's suspended state instead of excluding.

### group push mapping skips users okta

Skipping is the correct behavior once the mapping excludes inactive users. Verify the skip list is intentional.

## Why it happens

Okta pushes group membership as a list of member references, and most apps reject a membership add for a user that does not exist or is not active on their side. When Okta deactivates a user, the user mapping stops syncing them, but the group push still references them, so the whole membership update fails on those entries.

## Edge cases

- Reactivating a user re-triggers both user provisioning and group membership; expect a burst of tasks
- Some apps delete group membership on user deactivation instead of failing; know your app's behavior
- Filtering by status in the mapping can hide real failures; review the skip list quarterly

## If it still fails

- Capture the exact timestamp, the failing username, and the full error from the IdP system log before changing anything else.
- Reproduce with a single test user so you are not debugging a crowd.
- Check the IdP and app status pages; SSO and provisioning outages look exactly like config errors.
- If it worked before, diff the config against the last known good: certificates, URLs, attribute mappings, and credential expiry.
- Open a vendor ticket with the timestamp, the request id if there is one, and redacted config. Never send secrets or private keys.

## Prevention

- Track certificate and credential expiry with alerts, not memory.
- Run a synthetic login per SSO app daily so breakage pages you, not a user.
- Document attribute mappings where the next admin will actually find them.
- Test provisioning with a single user before bulk changes.
- Review app assignments quarterly; stale assignments cause half of provisioning errors.

## Provenance

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