SCIM 409 conflict" user already exists when provisioning
Fixes SCIM 409 conflict errors during provisioning by finding the pre-existing target account and linking it to the Okta user instead of creating a duplicate. Use when provisioning fails with 409 user already exists. Not for 400 mapping rejections or 401 connector auth failures.
TL;DR
A SCIM 409 means the target app already has an account with the same userName or email. Do not force the create. Find the existing account, link it to the Okta user through the app import, and let provisioning manage it from there.
"SCIM 409 conflict" user already exists when provisioningUse this when
- Provisioning a user returns 409 conflict from the target app.
- The user was created manually in the app before Okta managed it.
- The error names userName or email as the conflicting attribute.
Not for this skill when
- The error is a 400. That is a mapping problem.
- The conflict is on the Okta side (duplicate login). Fix it in Okta first.
- The target account belongs to a different person. That is a data problem, not a provisioning problem.
Steps
- Search the target app for the conflicting userName or email. Verify: you found exactly one existing account.
- Confirm the existing account belongs to the same person as the Okta user. Verify: email, name, or employee ID match.
- In Okta, run the app's import to bring the existing account in and match it to the Okta user. Verify: the match is confirmed, not auto-matched to the wrong person.
- Push a profile update to the linked account. Verify: the update applies cleanly.
- Re-run provisioning. Verify: no 409, and the account is now Okta-managed.
Variant phrasings
SCIM 409 on create
The status-first phrasing.
"user already exists" provisioning
The message-first search.
Okta duplicate userName target
The cause-first phrasing.
Compatibility: Okta SCIM 2.0 provisioning to any target app, Classic and Okta Identity Engine.
Why it happens
SCIM create is not idempotent on userName. Accounts created manually in the target before Okta took over provisioning still occupy the userName, so the create collides.
Edge cases / pitfalls
- Soft-deleted accounts in the target still reserve the userName on some apps; purge or restore them first.
- Case differences: some apps treat User@example and user@example as the same account.
- Auto-matching during import can link the wrong person when names are similar; confirm matches manually for the first pass.
- The existing account may have entitlements the Okta mapping will overwrite; review before linking.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_Ax41zUsyxdQ5qvArrqqO4g