Troubleshooting Common Issues with SCIM

Files.com creates and updates users, groups, and memberships from what your Identity Provider (IdP) sends in its SCIM requests. Files.com applies what arrives and nothing more, so when data in Files.com is missing or out of date, the usual reason is that the IdP has not sent it.

Start in the Settings Changes log, which records SCIM provisioning activity alongside your other site-level configuration changes. Creates, updates, and deletes for SCIM-managed users and Groups appear there, and the log summarizes membership-only changes as member updates.

SCIM Logs record every SCIM request Files.com receives and the response it returns, including requests that failed or changed nothing. A provisioning attempt that never reached the Settings Changes log still appears in SCIM Logs, with the response code that explains why.

When the action you are chasing appears in neither log, the IdP never sent it, and your IdP's own provisioning logs hold the reason.

Login Failures After an Email or User Name Change

When you change a user's email address, user principal name (UPN), or username after SCIM has provisioned that user, Files.com keeps the previous value until the IdP sends the update. The user can be locked out of Files.com until the update arrives.

IdPs send the change on their scheduled sync interval, so the wait lasts until the next cycle runs. On-demand provisioning pushes the change immediately and closes the gap.

Duplicate Users and Login Errors Without SCIM

Duplicate users and login errors come from the same gap. Without SCIM, Files.com has no way to learn that a changed UPN or email address belongs to a user it already has.

With Automatically provision users on first login enabled, Files.com reads the new address as a new person and creates a second user record. The original account stays behind as a duplicate.

With Automatically provision users on first login disabled, the login returns an error instead. Files.com does not recognize the address being presented and does not create an account for it.

Configuring SCIM removes both the duplicate and the error, because the IdP sends the changed address as an update to the user Files.com already manages. On-demand provisioning applies that update right away.

Manually Deleted Users Fall Out of Sync

Deleting an SSO-provisioned user directly in Files.com leaves the IdP out of sync. The IdP still reports the user and their groups as provisioned. The account no longer exists in Files.com, and nothing in the IdP flags the difference.

Deactivate the user in the IdP, then reactivate them. That sends a fresh set of user update requests to Files.com and restores the account. The IdP's group provisioning tools do not restore users, so re-pushing the group will not bring the account back.

Missing Groups or Group Memberships

Group and membership data goes missing when your IdP leaves it out of its SCIM payloads. The group type may be unsupported by the IdP's SCIM implementation, the group may fall outside the provisioning scope you configured, or the group's metadata may be invalid.

In Microsoft Entra ID these problems are specific to SCIM provisioning, and they come from the way Entra sequences its sync cycles. Entra's SCIM requests also leave out the membership data that the group-based provisioning filters rely on. When consistent group membership sync matters in an Entra environment, LDAP provisioning reads memberships from your directory on a schedule instead.

The fix is on the IdP side, because that is where the missing data sits. Modify the group or user in your IdP, use its on-demand provisioning feature, or push the change through the IdP's API. Each of these triggers reprocessing.

When your IdP cannot re-evaluate objects in bulk, updating the affected records by hand is the only route.

Other Causes of Incomplete Provisioning

Throttling and rate limits in the IdP silently delay or skip provisioning actions during a high-volume synchronization. An incomplete SCIM payload, one missing a required attribute or identifier, causes the provisioning request to fail. Scope filters and inclusion rules exclude users and objects you expected to see provisioned. Misconfigured attribute mappings, outdated records, and deleted entries the IdP no longer reprocesses produce the same result.

When your IdP has no on-demand provisioning, you can update the affected records by hand or restart the synchronization cycle.