SCIM - Groups Not Syncing Users Properly

  • SCIM with Entra ID
  • SSO and SAML groups previously working
  • Groups are showing up but getting user errors, only some users are showing up in groups.
  • The existing users are the ones not mapping
  • Group names are the same in Entra and in SonarQube
  • Error:
    • Provision urn:ietf:params:scim:schemas:extension:enterprise:2.0:User in customappsso

    • Description Failed to create User ‘*******@company.org’ in customappsso

We’ve been using SSO with SonarQube Cloud since we setup or Enterprise and org in Sept 2025. I’m adding SCIM, no changes to SSO, and it revalidated successfully after SCIM setup. I’ve followed all the instructions, including the additional flag for Entra ID, and everything is green and syncing, but we’re getting provisioning errors in Entra that it can’t create the users. Below are the attribute mappings for SSO and SCIM. Both have userName = userPrincipalName as the match key, but the attribute mapping for the name setup appears to be backwards. For new users (added with SCIM) the userPrincipalName is showing up in the ID and the display name is the “name” of the member, but the ones that existed (from SAML) are the opposite way.

SCIM- Name: userPrincipalName, ID: display_name (Example- John Smith, smithj@mycompany.org-ABCd@saml-{UUID})

SAML/SSO - Name: displayName, ID: userPrincipalName (Example- SmithJ, John.Smith@mycompany.org-ABCd@saml-{UUID})

How do I get the provisioning to properly pull members into the groups? Do I need to somehow fix the name attribute mapping first?

SSO:

SCIM:

Hi Jennifer,

I will send you a direct message to request the email of an affected user so that I can verify on my side.

From looking at your screenshots, it seems that the login attribute may not be correctly configured for your SSO config.

Most likely, you can follow those steps to fix it :

  1. Fix the login attribute claim (this was marked as a required attribute in SSO config page) as explained in the docs here.

  2. Ask the affected users to re-login as this will update the username attribute in Auth0.

  3. Once all the affected users have logged in back, they could trigger provisioning on demand (or wait for the next provisioning cycle) which should result in successful SCIM operation.

The login attribute in SSO should be the same as the username attribute in SCIM provisioning. If they are both mapped to userprincipalname then it should work.