Troubleshoot SCIM provisioning

Resolve identity provider (IdP) reporting errors, missing users, incorrect permissions, or failed deactivations. First, check your IdP's provisioning log to inspect the request payload and Celigo's HTTP response status. Next, check the Celigo audit log (filtered by source SSO) to verify what Celigo recorded.

Your identity provider's provisioning log shows the status Celigo returned and, for most failures, the detail text.

A SCIM problem shows up in three places: the identity provider's provisioning log, which carries the request and Celigo's response; the Celigo Users lists, where a person is missing, disabled, or holds the wrong access; and the Celigo audit log filtered by source SSO, which records what Celigo actually changed.

The IdP reports 401 Unauthorized

A 401 means Celigo rejected the token or the configuration, not the person being provisioned. Check these causes in order.

1. The token was revoked. Someone selected Revoke on the slot the IdP was using, and the slot now reads No token generated. Generate a token and update the IdP.
2. SCIM provisioning is turned off or unsaved. Open the configuration and confirm that SCIM provisioning is selected and saved. Turning it off revokes both tokens, so after turning it back on you need new ones.
3. The base URL points at the wrong configuration. Each configuration has its own base URL and tokens, and a token pasted against another configuration's URL fails. Copy the URL and token from the same section.
4. For end users, the identity provider was deleted. Deleting an identity provider deletes its SCIM configuration and tokens. Set SCIM up on its replacement. Disabling an identity provider doesn't stop its SCIM pushes.
5. For workspace users, SSO is turned off. The workspace configuration depends on the account's SSO configuration. Turn SSO back on.
6. The token was entered without the Bearer scheme. Celigo accepts the token only as Authorization: Bearer <token>. Okta's SCIM 2.0 Test App (Header Auth) sends its API Token field as the header value exactly as typed, so enter Bearer, a space, and then the token there. Okta reports this as Error authenticating: Unauthorized. Errors reported by remote server: Unauthorized.

The IdP reports 403 Forbidden

Your subscription no longer includes SCIM provisioning or single sign-on (SSO). Until the subscription includes both again, Celigo rejects every SCIM request with the detail insufficientLicense, even when the token is valid. Users the IdP already provisioned aren't affected. Contact your Celigo account manager.

The IdP reports 429 Too Many Requests

Celigo limits SCIM requests per source IP address, and a large initial synchronization that sends hundreds of requests at once can reach the limit. IdPs retry throttled requests on their own schedule, so wait for the synchronization to finish. Celigo's response carries no Retry-After header. If the IdP keeps failing on the same people, reduce the assignment batch size or contact Celigo Support.

A user was assigned but never appeared

A person who doesn't reach Celigo has almost always been rejected with a 400 or a 409. Check the request's status in the IdP's provisioning log.

1. 400 with Email domain is not allowed for this IdP configuration. End users only. The identity provider routes Specific email domains and this person's domain isn't listed. Add the domain to the identity provider, or assign the person to the SCIM application of the identity provider that routes their domain.
2. 400 with userName must be a valid email address or userName is required. The IdP's userName mapping isn't sending an email address. Map userName to the person's email.
3. 400 with Content-Type is required for this request. The request had no Content-Type header. Celigo accepts application/scim+json and application/json.
4. 400 with userName and email are immutable. The IdP tried to change an existing user's userName, or sent a PATCH that replaces emails. This happens when the IdP's matching rule found the person by externalId and their email changed in the directory, or when the userName and emails mappings read different source attributes. Change the email in Celigo first, then let the IdP retry.
5. 409 with User already exists under a different IdP configuration. End users only. Another identity provider's SCIM configuration already manages this person. Assign them to one SCIM application only. If their domain isn't routed to this identity provider, the domain 400 fails first.
6. 200 or 201, but you can't find them. Search Account > Users by email, and for end users open End users > Users. A 200 means the person already existed and Celigo adopted them, so look for the existing record rather than a new one.

An existing user produced no error

Celigo adopts an existing user instead of returning a conflict, so no error appears in the identity provider's log. Turning SCIM on for an account with dozens of invited users produces no errors to clean up. The audit log shows an update entry with source SSO for each adopted user.

A pushed group didn't give anyone access

1. The name doesn't match. Matching is exact and case-sensitive, so Finance Team and finance team are different groups. Compare the IdP group name with the Celigo group name character by character, then rename one of them. Okta matches group names without regard to case, so if Celigo has two groups whose names differ only by case, Okta's push fails with Incorrect result size: expected 1, actual 2 and no membership arrives. Rename or delete one of the two.
2. Celigo created a new group. When no name matched, Celigo created a group with that name and no MCP servers. Open it under End users > Groups and assign servers and capabilities, or delete it and fix the name. A group whose name is an ID string came from a user groups entry that carried only a value — map the group name to display instead.
3. The IdP is sending role names instead of group names. Values mapped to the EndUser roles attribute are matched to end-user roles, not groups, and a name that matches no role is ignored. Map group memberships to groups or push them as groups, and map roles only to names of roles that exist in Celigo.
4. The membership was removed in Celigo, or by a profile push. Memberships the IdP manages come back on the next push, so remove the person from the group in the IdP instead. A user push that carries an empty groups list removes every membership the IdP manages. In Okta, select Push Now on the group to restore them.

Access level doesn't match the IdP

1. The value isn't recognized. Celigo accepts administrator, manage, monitor, and none, plus the aliases listed in Provision workspace users with SCIM. On create, an unrecognized value becomes none. On update, Celigo keeps the current level. A user whose access level is none shows an empty Role cell in Account > Users.
2. The attribute isn't in the mapping. If the IdP doesn't send accessLevel, new users get none and existing users keep what they have. Add the mapping.
3. The person is the account owner. SCIM never changes the owner's access level. The audit log shows accessLevel:<value> (ownership changes require transfer).
4. Someone changed it in Celigo. SCIM sets it back on the next push. Change access levels in the IdP.

A user wasn't deactivated

1. The person is the account owner. SCIM can't deactivate the owner. The audit log shows deactivate (ownership changes require transfer). Transfer ownership first, then deactivate. See Provision workspace users with SCIM.
2. The IdP sent DELETE instead of active: false. Celigo answers DELETE with 501, changes nothing, and writes no audit entry. Configure the IdP to deactivate people rather than delete them; most do this by default when you unassign someone. Microsoft Entra ID also sends DELETE when a person is permanently deleted, unless you clear the Delete target object action in the attribute mapping. OneLogin sends it when its action for deleted users is Delete instead of Suspend, and Auth0's stock Action template sends it on user.deleted.
3. The person is the other user type. End-user SCIM disables the end-user membership only, and workspace SCIM disables the workspace membership only. A person who is both needs both configurations.
4. You unassigned a group instead of its members. Unassigning a group doesn't remove its memberships or deactivate anyone. Microsoft Entra ID sends DELETE for the group, Celigo rejects it, and the group keeps its members and their access. Remove the members in the IdP before you unassign the group, or remove them from the group in Celigo now.

Deleted Entra ID user is still active

Microsoft Entra ID sends DELETE for a permanently deleted person, and Celigo answers 501 without changing the user or writing an audit entry. Only active: false deactivates someone, and Entra ID sends it on its next provisioning cycle for a person who was disabled, unassigned, or soft-deleted. If you permanently deleted the person before that cycle ran, for example straight after the soft delete, Celigo never received active: false and the person stays active with their access level or groups. Entra ID's provisioning log shows the failed delete; Celigo's audit log shows nothing. Deactivate the person in Celigo yourself. Next time, disable or unassign people in Entra ID and let a cycle run, or provision them on demand, before you delete them. See Set up SCIM provisioning with Microsoft Entra ID.

Disabled user is active again

The IdP owns active. Many IdPs send active: true on every update, and Celigo re-enables the user when it arrives. Deactivate the person in the IdP, or unassign them from the SCIM application.

Reactivated Okta user stays disabled

Deactivating a person in Okta removes their app assignments along with sending active: false, so activating them again in Okta restores the Okta account but pushes nothing to Celigo. Assign the SCIM application to the person again, directly or through a group. Okta then sends active: true, and Celigo re-enables them with their previous access level or memberships.

Deactivated user can still call the API

Deactivation revokes the personal access tokens the person created in your account. It doesn't revoke API tokens, which belong to the account. Go to Resources , and then select API tokens, find the token the call is using, and revoke it.

Provisioning stopped completely

When every request fails for a while, some identity providers switch provisioning off rather than keep retrying.

• Microsoft Entra ID quarantines the job. After most requests fail, for example with 401 once a token is revoked, Entra ID puts the provisioning job in quarantine, slows the cycle to once a day, and emails the notification address on the application. After 4 weeks in quarantine it disables the job. Fix the cause, then select Restart provisioning. See Set up SCIM provisioning with Microsoft Entra ID.
• Auth0 disables the event stream. After 500 consecutive failed deliveries, Auth0 switches the stream off. A bulk deletion of people who were never blocked reaches that threshold quickly, because Celigo rejects every DELETE. See Set up SCIM provisioning with Auth0.

Prevention

• Deactivate or unassign people in the identity provider and let a cycle run before you delete them there. Only active: false deactivates someone in Celigo.
• Deactivate people in the identity provider rather than in Celigo. Many identity providers send active: true on every update and re-enable anyone you disabled by hand.
• Create the Celigo end-user groups, with their MCP servers assigned, before you push group names. A name that matches nothing creates an empty group that grants no access.
• Keep the account owner a shared mailbox that isn't in your directory, so your identity provider never tries to deprovision it.
• Change a person's email in Celigo first, then in the identity provider.

Related articles

• SCIM provisioning overview
• Provision workspace users with SCIM
• Provision end users with SCIM
• View or download your audit logs