## Troubleshooting SCIM provisioning URL: https://docs.atlan.com/product/integrations/identity-management/scim/troubleshooting/troubleshooting-scim-provisioning > Troubleshoot common SCIM provisioning issues in Atlan, including missing group members, username conflicts, token expiry, and identity provider sync behavior. Atlan supports SCIM provisioning for [Azure AD](https://docs.atlan.com/llms/governance/access-control/enable-azure-ad-for-scim-provisioning/llms.txt) and [Okta](https://docs.atlan.com/llms/governance/access-control/enable-okta-for-scim-provisioning/llms.txt). Each section below covers a common question or issue, its cause where applicable, and how to resolve it. ## Users missing from SCIM-mapped groups :::note Symptom After enabling SCIM, some users who already existed in Atlan do not appear in their expected groups, even though those users are members of the mapped SSO group. No sync errors are reported. ::: ### Cause Atlan matches the incoming SCIM `userName` field against the existing Atlan username exactly. Users who were invited to Atlan before SCIM was enabled often have the email prefix as their username (for example, `amorris`), while the SSO provider sends the full email address as `userName` (for example, `amorris@yourcompany.com`). Because the values don't match, the lookup returns no result and the user is skipped during group sync. SCIM does not raise an error for unmatched users. The sync completes successfully even when members are skipped, so the mismatch can go unnoticed until you compare expected and actual group membership. ### Solution 1. In Atlan, go to **Admin > Users** and compare the **Username** column with the format your SSO provider sends as `userName` (typically the full email address). Note any users whose Atlan username is the email prefix or otherwise differs from the SCIM `userName`. 2. Because [usernames in Atlan are immutable](#usernames-cannot-be-changed-after-scim-provisioning), resolving this mismatch requires Atlan support to run a one-time backend update. [Contact Atlan support](https://ask.atlan.com/hc/en-us/requests/new) with the list of affected users. Provide each pair as `oldUsername` and `newUsername`, for example: ```json [ { "oldUsername": "amorris", "newUsername": "amorris@yourcompany.com" }, { "oldUsername": "joleson", "newUsername": "joleson@yourcompany.com" } ] ``` 3. After Atlan support completes the update, the next SCIM sync from your SSO provider matches the affected users and adds them to their mapped groups. The update preserves asset ownership, group membership, personas, and policies for affected users. Audit log entries created before the update retain the old username, and any user-typed custom metadata that references the old username is not rewritten. --- ## Username already exists in Atlan :::note Symptom A user from your SSO provider is not synced to Atlan, even though the user exists in the mapped SSO group. ::: ### Cause If a user with username `user.name` and email `xyz@example.com` already exists in Atlan, and your SSO provider attempts to provision a different user with the same username `user.name` but a different email address (for example, `abc@example.com`), a conflict occurs. Atlan does not overwrite the existing user. The existing user remains in Atlan and the new SSO user is not synced. ### Solution 1. In Atlan, go to **Admin > Users** and search for the conflicting username. 2. Determine whether the existing user in Atlan is the correct account. If the existing account is no longer needed, [remove the user](https://docs.atlan.com/product/capabilities/governance/users-and-groups/how-tos/manage-users) before the next SCIM sync. 3. If both accounts are legitimate, [contact Atlan support](https://ask.atlan.com/hc/en-us/requests/new) to resolve the conflict. --- ## Usernames cannot be changed after SCIM provisioning Once SCIM is enabled, usernames of provisioned users are controlled by your SCIM provider and cannot be updated in Atlan. Atlan uses the username as a unique identifier across the platform. If a username changes in your SSO provider (for example, due to a migration or automation), the updated username does not propagate to Atlan. To resolve a username mismatch, [contact Atlan support](https://ask.atlan.com/hc/en-us/requests/new). --- ## What Atlan syncs from your identity provider Atlan syncs the user's first name, last name, username, email address, group information, and user status through group mapping. The username and email address are synced only once, when the user is provisioned in Atlan for the first time. --- ## What happens if an SSO or Atlan group is renamed If SCIM provisioning is enabled and an SSO group that is mapped to Atlan is renamed, the change syncs automatically. Renaming an Atlan group does not affect SCIM functionality. --- ## What happens if an SSO group is deleted If an SSO group is deleted in your identity provider, the group mapping is also deleted in Atlan. The corresponding Atlan group remains active, but all users are removed from it. To retain group membership in Atlan, delete the group mapping in Atlan first, then delete the SSO group in your identity provider. --- ## What happens if a user is deleted from the SSO provider If a user is removed from your SSO provider, the same user is [deactivated in Atlan](https://docs.atlan.com/product/capabilities/governance/users-and-groups/how-tos/manage-users) and their status is shown as _Disabled_. To permanently delete the user from Atlan, you can [remove the user and transfer ownership of assets](https://docs.atlan.com/product/capabilities/governance/users-and-groups/how-tos/manage-users). --- ## Deactivated identity provider users stay active in Atlan If you deactivate or disable a user in your identity provider but they remain **Enabled** in Atlan, your SCIM application is most likely not sending the `externalId` attribute (the identity provider's stable object ID, such as the Azure AD Object ID). Atlan matches incoming SCIM updates to existing users by `externalId`, so without it, a deactivation cannot be applied to the right user. To fix this, open your identity provider's SCIM (provisioning) application and confirm it maps and sends `externalId` to Atlan. In Microsoft Entra ID (Azure AD), check the SCIM attribute mappings on the enterprise application used for provisioning and ensure the Object ID is mapped to `externalId`. After correcting the mapping, the next provisioning cycle reconciles user status. --- ## When does the SCIM token expire The SCIM token does not expire by default and can only be revoked by deleting it. --- ## Can user removal affect SCIM tokens Yes, [removing a user](https://docs.atlan.com/product/capabilities/governance/users-and-groups/how-tos/manage-users) also deletes any SCIM tokens that user created. For more guidance, see the [User management FAQ](https://docs.atlan.com/llms/governance/faq/user-management-and-access-control/llms.txt). --- ## Does SCIM provisioning require a user to log in first No, SCIM provisioning works as soon as a user has been provisioned from the SSO provider. The user profile can be updated or the user disabled in Atlan directly from the SSO provider, even before the user has logged in. If SCIM is enabled and a user has never logged into Atlan, their status is _Enabled_ by default. Once the user logs in, their last login activity appears in the _Last Active_ column. --- ## Assigning SCIM provisioned users as asset owners before first login Yes, you can assign [asset ownership](https://docs.atlan.com/llms/catalog/discovery/add-owners/llms.txt) to SCIM provisioned users before they have logged into Atlan for the first time. ---