Why does SCIM provisioning create duplicate users?

SCIM provisioning usually creates duplicate users when the identity provider and the target app don’t match on the same unique identifier or when the app’s SCIM implementation can’t reliably recognize an existing account.

Common causes:

1. Email is used instead of a stable unique ID

   • If matching is based on email/username and that value changes, SCIM may think it’s a new user.
   • Better: use a permanent identifier like externalId or the IdP’s immutable user ID.

2. The app doesn’t support SCIM “update” matching correctly

   • Some apps create a new account on every “Create User” request if they can’t find an exact match.
   • They may ignore externalId, userName, or case differences.

3. Case sensitivity or formatting mismatches

   • John.Doe@example.com vs john.doe@example.com
   • Leading/trailing spaces, aliases, or different domain formats can cause a miss.

4. Users were pre-created manually

   • If the app already has a manually created account, SCIM may not link to it automatically.
   • Result: SCIM provisions a second account.

5. Multiple identity sources are provisioning the same app

   • Example: two IdPs, or both SAML JIT and SCIM, each creating users.

6. Reassignment / deprovisioning quirks

   • If a user is deactivated and then reactivated, some systems create a new account instead of restoring the old one.

How to avoid it:

• Use a single, immutable identifier for matching (externalId is common).
• Ensure the app’s SCIM connector supports idempotent create/update behavior.
• Standardize the username/email format.
• Avoid mixing manual user creation with SCIM for the same app.
• Check whether the app can link existing users before provisioning.

If you want, I can help you diagnose the exact cause for a specific IdP/app pair (e.g., Okta → Slack, Entra ID → Jira, Google → GitHub).