provisioning agent created duplicate accounts: SCIM username case mismatch error fix

TL;DR

Treat usernames as case-insensitive everywhere even when one system preserves case. Find the duplicate pair, pick the canonical lowercase form from the HR source, merge or remove the stray account in the target, fix the source value and the SCIM matching configuration so creates compare case-insensitively, then re-sync and confirm one account remains.

provisioning agent created duplicate accounts: SCIM username case mismatch

Use this when

• The target app holds two accounts for one person whose usernames differ only in capitalization.
• Duplicates appear after HR data entry, a directory migration, or a feed change altered username casing.
• Updates land on one account while sign-in uses the other, causing confusing profile drift.

Not for this skill when

• Two accounts belong to different people with genuinely similar usernames. Follow identity verification, not merging.
• The duplicate was created manually inside the app with a different email as well. Use the general duplicate cleanup workflow.

Steps

1. List the target app accounts for the affected person and record both usernames exactly as stored, plus each account creation source, last activity, and linked externalId. Determine which account holds real usage such as files, tickets, or history that must survive. Verify: both accounts are inventoried with a clear survivor candidate
2. Check the HR and directory source values for the username across every feed that writes it, hunting for the variant that introduced capitals, often a manual HR edit or a second source such as a contractor feed. Verify: the source of the capitalized variant is identified
3. Normalize the canonical username to lowercase in the authoritative source and in any transform the SCIM connector applies, and confirm the identity platform matching rule compares userName without case sensitivity where the setting exists. Verify: source and transform both emit the lowercase form
4. Merge safely in the target: transfer ownership of content from the stray account to the survivor where the vendor supports it, deactivate the stray, and keep it deactivated through one full sync cycle before deletion so no step recreates it. Verify: the survivor holds the content and the stray shows deactivated after a sync
5. Re-run provisioning for the person and confirm the connector matches the survivor, updates it, and creates nothing new. Check sign-in with the canonical username and confirm profile attributes land on the account the person actually uses. Verify: one active account remains and updates flow to it
6. Sweep the target for other case-duplicate pairs with a case-insensitive username report and remediate the handful found, then add a data entry note in HR that usernames are issued lowercase only. Verify: the sweep report shows no remaining case-duplicate pairs

Why it happens

SCIM defines userName matching as case-insensitive in the specification, but real implementations vary: some stores preserve the case sent on create and compare exactly on later operations, while sources freely change case through manual edits. When the source sends a differently cased value, the connector match misses, the create path runs, and the target uniqueness check, if also case-sensitive in practice, allows a second account. One person then lives as two identities. Normalizing case at the source and confirming connector matching behavior closes the gap the specification assumes away.

Variants and edge cases

Target enforces case-sensitive uniqueness by design

A few legacy apps treat case variants as distinct accounts intentionally. For those, pin the exact stored case in the mapping per app and never normalize downstream of the connector.

Duplicates in the source directory itself

If the directory holds both variants, fix the directory first and let SCIM follow, otherwise the target merge will be undone on the next cycle.

Email local part case differences

Email systems are case-insensitive in practice but some matching rules compare exactly. Apply the same lowercase normalization to the email used as a secondary matcher.

Compatibility: Applies to SCIM 2.0 provisioning from Okta, Entra ID, and similar platforms to SaaS targets. Requires admin rights in the source directory and the target app.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6gQyN-fDmT-og5xRGHqi6Q