# Troubleshoot SCIM
The table below describes several errors you may encounter when SCIM is enabled for your identity provider.
| Issue | Description | Resolution |
| ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Access is not syncing in the data platform for a user who has been granted access in Immuta | If the access granted or revoked is not reflected in your data platform, this could indicate that usernames are not properly set in Immuta or the user account has been orphaned. | |
| Usernames do not match between Immuta and the identity provider or data platform | If the username in Immuta does not match the username in the identity provider or data platform, it could be because the user account in Immuta was created before the user account was created in the identity provider or data platform or because the username changed in the identity platform after the user was provisioned in Immuta. | To update the username in Immuta, delete the user and provision a new one. |
| User account is disabled in Immuta, but not in my identity provider | If a user account is disabled in Immuta but still exists in the identity provider, the account will be re-enabled when the identity provider attempts to create that user through SCIM. | Disable the account in your identity provider. |
| Group provisioning updates are failing or timing out | Immuta processes incremental, standards-compliant SCIM updates. If these group membership updates are too large, there is a risk that the update will error or timeout. | Use the `PATCH` SCIM method to provide partial updates to your groups, and batch these group membership updates to approximately 100 users per request. Batching group membership updates helps mitigate the risk of provisioning timeout errors and failures. See the [SCIM protocol page](/saas/configuration/people/section-contents/reference-guides/scim-protocol.md#provisioning-group-updates) for guidance. |
| Changes made to the user account in my identity provider are not reflected in Immuta | If you notice this issue, it could be because of a username mismatch, an orphaned user account, or group provisioning updates are not syncing. | |
## Resolutions
Use the guidance below to troubleshoot common errors when configuring SCIM.
### Usernames fail to match between Immuta and the identity provider or data platform
If you see that the username in Immuta does not match the username in the identity provider or data platform, it could be because the user account in Immuta was created before the user account was created in the identity provider or data platform or because the username changed in the identity platform after the user was provisioned in Immuta.
If a username changes in the identity provider after the user has already been created in Immuta, SCIM will not update the username in Immuta, and the account with the old username will remain active in Immuta even though the username is no longer valid in the identity provider.
To update the username in Immuta, delete the user and provision a new one.
### User account is disabled in Immuta, but not in my identity provider
If a user account is disabled in Immuta but still exists in the identity provider, the account will be re-enabled when the identity provider attempts to create that user through SCIM. Re-enabling the account and syncing the profile data allows the user to be restored to active status without conflicts. This behavior ensures that SCIM provisioning remains the authoritative source and allows users who were deleted in Immuta to be automatically restored when re-provisioned by the identity provider.
Identity providers would typically attempt to re-create the user through a scheduled sync or reconciliation process, but the timing depends on your identity provider's provisioning configuration. Once the identity provider sends the request, Immuta automatically handles re-enabling the disabled account.
To ensure the user account remains disabled in Immuta, disable the account in your identity provider.
### Group provisioning updates are failing or timing out
Immuta processes incremental, standards-compliant SCIM updates. To ensure that group membership changes are synced reliably,
1. Use the `PATCH` SCIM method to provide partial updates to your groups.
2. Batch these group membership updates to approximately 100 users per request.
Batching group membership updates helps mitigate the risk of provisioning timeout errors and failures. If you encounter SCIM provisioning errors related to group membership updates, reduce the batch size. See the [SCIM protocol page](/saas/configuration/people/section-contents/reference-guides/scim-protocol.md#provisioning-group-updates) for guidance.
### User accounts are orphaned in Immuta
If a user account existed in Immuta before it existed in the identity provider when SCIM was enabled, the user would remain in Immuta without being managed by your identity provider through SCIM. The SCIM protocol is push-based, so Immuta doesn't proactively reach out to the identity provider to validate user existence. If the user doesn't exist in the identity provider, the identity provider won't send the `DELETE` request, so Immuta won't delete them. The user becomes orphaned when they exist in Immuta and are tied to that IAM, but they're no longer actively provisioned or managed by the identity provider.
To resolve this issue,
1. Confirm whether or not the user account exists in your identity provider.
2. Remove or reconcile the user account:
Remove an orphaned user account
If you want this user to be removed, an administrator must complete one of the following actions:
* Manually delete the user in Immuta
* Configure the identity provider lifecycle management to send an explicit `DELETE` request through SCIM to remove users not found in its directory
Immuta does not initiate `DELETE` operations; it only responds to requests from the identity provider, so orphaned users persist until explicitly removed.
Reconcile an orphaned user account
If the user account is later added to the identity provider and it attempts to create that user via the SCIM `POST` endpoint, it would receive a `409 Conflict error` rather than syncing with the existing Immuta account. There is no automatic reconciliation or linking. The orphaned Immuta user would need to be manually deleted in Immuta first, and then the identity provider could re-create them.
Immuta's SCIM implementation doesn't automatically detect or merge pre-existing users with newly provisioned ones through SCIM.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://documentation.immuta.com/saas/configuration/people/section-contents/reference-guides/scim-protocol/troubleshoot-scim.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.