# Fix Okta SCIM provisioning failing on group push

## TL;DR
Group push fails when the target app group cannot be created or linked, usually a name clash or a missing group schema in the connector. Rename the conflicting group or fix the push mapping, then retry the push from the Okta group page. Do not keep re-pushing the same group while the target errors, it queues failures.

## The error
```text
Okta provisioning task: Push Groups
Status: Failed
Error: Unable to create group in target application
```

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

## Fix it

### Step 1: Read the exact failure in the Okta task log

```bash
Okta Admin -> Directory -> Groups -> [group] -> Apps -> [app] -> Provisioning, then open the most recent failed task.
```

Expected: You see the concrete error: name conflict, bad characters, or a connector rejection, not just Failed.

### Step 2: Check for a name clash in the target app

```bash
curl -s "https://yourapp.example.com/scim/v2/Groups?filter=displayName+eq+%22[Group Name]%22" \
  -H "your auth header bearer value]"
```

Expected: If a group already exists with that displayName, the push is colliding. If none exists, the connector is rejecting the create.

### Step 3: Fix the clash: link or rename

```bash
Either link the Okta group to the existing app group (Edit group push mapping -> Link), or rename the Okta group so the displayName is unique.
```

Expected: The push mapping shows Linked or a fresh unique name with no conflict warning.

### Step 4: Retry the push for one group

```bash
On the group page, choose Push now or retry the failed task for a single group before doing the rest.
```

Expected: The task flips to Success and the group appears in the target app.

### Step 5: Verify memberships flow

```bash
Add a test user to the Okta group and watch the provisioning log.
```

Expected: A membership update task succeeds within a couple of minutes.

## When this applies

- Okta group push to a SCIM app fails while user provisioning works
- Group tasks fail with create or update errors in the target app
- You are debugging a SCIM connector that handles groups

## When it doesn't

- User provisioning itself fails (check user push errors instead)
- Groups push fine but members never sync (that is a membership mapping issue)
- The app has no SCIM group endpoint at all (group push is unsupported there)

## Compatibility

Okta group push with SCIM 2.0 connectors. Behavior matches across Okta Classic and Okta Identity Engine.

## Variant phrasings

### okta push groups failed target application

Same fix path. The target app is the authority on why the create was refused, so its logs matter more than Okta's.

### okta group push mapping failed

Mapping failures usually mean the Okta group name contains characters the app rejects. Rename in Okta and re-push.

### scim group creation failed 409

The group already exists under a different id. Link instead of create.

## Why it happens

Group push is a separate SCIM call path from user provisioning and it has its own failure modes. The usual ones: the app already has a group with that displayName, the group name has characters the app rejects, or the connector maps the group to a schema the app does not support. Okta retries push tasks on a schedule, so an unfixable mapping just keeps failing.

## Edge cases

- Nested Okta groups do not push as nested app groups in most connectors; flatten first
- Deactivating the app group in the target breaks the link silently; re-link after restore
- Very large groups can time out the push; push the group first, then add members in batches

## 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_7xndLT4dL5pi-Jm0ij1VGQ