Microsoft Entra customappsso silently drops custom SCIM extension attributes from outbound POST body despite UI showing them as "Modified (successful)"

Gaston Rios Cardona 0 Reputation points
2026-06-02T00:15:38.01+00:00

Hey there.

We've configured a custom SCIM provisioning Enterprise Application in Microsoft Entra ID and have hit a behavior where custom extension URN attributes are silently dropped at serialization, even though the Entra portal's Modified attributes (successful) panel and the Provisioning Logs both report them as successfully written. We're looking for either confirmation that this is a current customappsso limitation, or guidance on the correct way to register custom SCIM extension schemas so they're serialized onto the wire.

Our setup

  • Target: a SCIM 2.0–compliant service (a Java SCIM-SDK implementation) exposed at /v2/. The target's /Schemas endpoint advertises three User schemas:
    • urn:ietf:params:scim:schemas:core:2.0:User
    • urn:co.humand:params:scim:schemas:extension:1.0:User (static extension with attributes hiringDate and birthdate)
    • urn:co.humand:params:scim:schemas:extension:instance:<tenantId>:1.0:User (per-tenant dynamic extension; each tenant has a different instance ID baked into the URN)
  • Enterprise App: Non-gallery, customappsso provisioning, Automatic mode, Bearer token auth, Tenant URL pointing to our SCIM endpoint. Test Connection passes.
  • Attribute mapping: configured via the portal UI. Core attributes (userName, name.givenName, name.familyName, emails[type eq "work"].value, phoneNumbers[type eq "work"].value, active, preferredLanguage) map correctly and flow on the wire. Three custom URN-prefixed targets were added via Edit attribute list for customappsso:
    Target attribute (declared as String) Source expression
    urn:co.humand:params:scim:schemas:extension:1.0:User:hiringDate FormatDateTime([employeeHireDate], , , "yyyy-MM-dd")
    urn:co.humand:params:scim:schemas:extension:1.0:User:birthdate FormatDateTime([extensionAttribute2], , , "yyyy-MM-dd")
    urn:co.humand:params:scim:schemas:extension:instance:2907:1.0:User:<uuid> (multi-value) Split([extensionAttribute1], ",")
  • The last entry corresponds to a profile field "Languages" and it is a list of strings.
  • Source values on the test user: confirmed populated via Microsoft Graph (onPremisesExtensionAttributes.extensionAttribute1, onPremisesExtensionAttributes.extensionAttribute2, employeeHireDate).

What the portal claims

After running Provision on demand on the test user, the portal shows step 4. Perform action → Success, and the Modified attributes (successful) panel lists all three custom URN attributes with computed values.User's image

The Provisioning logs → Modified Properties tab shows the same.

What actually goes on the wire

We tunneled the Tenant URL through ngrok and captured the HTTP POST request Entra sent. The full request body:

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User",
    "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
  ],
  "userName": "******@humand.co",
  "active": true,
  "emails": [{"primary": true, "type": "work", "value": "******@gmail.com"}],
  "meta": {"resourceType": "User"},
  "name": {"familyName": "Test", "givenName": "Scim"},
  "phoneNumbers": [{"primary": true, "type": "work", "value": "+54116847319"}],
  "preferredLanguage": "en"
}

None of the three custom URN attributes appear — not as nested envelopes ("urn:co.humand:...:User": { ... }), not as flat top-level keys ("urn:co.humand:...:User:hiringDate": "..."), nowhere. The schemas array also does not include any co.humand URN, even though the Modified attributes panel reported them as written. Note: the body declares urn:ietf:params:scim:schemas:extension:enterprise:2.0:User in schemas but no enterprise extension data is in the body either (no employeeNumber, no department, etc.).

Schema export confirms the attributes are declared

A GET on https://graph.microsoft.com/beta/servicePrincipals/{sp-id}/synchronization/jobs/{job-id}/schema confirms the three custom URN attributes are declared on the customappsso User object. Snippet:

{
  "directories": [
    ...,
    {
      "name": "customappsso",
      "objects": [
        ...,
        {
          "name": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
          "attributes": [
            ... core User and enterprise attrs ...,
            {
              "name": "urn:co.humand:params:scim:schemas:extension:1.0:User:hiringDate",
              "type": "String",
              "multivalued": false,
              "mutability": "ReadWrite"
            },
            {
              "name": "urn:co.humand:params:scim:schemas:extension:1.0:User:birthdate",
              "type": "String",
              "multivalued": false,
              "mutability": "ReadWrite"
            },
            {
              "name": "urn:co.humand:params:scim:schemas:extension:instance:2907:1.0:User:084ab23a-...",
              "type": "String",
              "multivalued": true,
              "mutability": "ReadWrite"
            }
          ]
        }
      ]
    }
  ]
}

So the schema knows the attributes exist and they're declared on the right object but the serializer ignores them.

What we've already tried

  • Save + confirm resync on the Mappings page (multiple times).
  • Stop / Start provisioning to clear any internal cache.
  • Deleting and re-adding the user in Users and groups.
  • Confirmed via curl directly against our SCIM endpoint that the endpoint correctly persists extension data when given a spec-compliant nested-envelope body. So the target works; the problem is the body Entra emits.
  • Confirmed via the same curl that our endpoint also accepts the flat URN-prefixed form ("urn:co.humand:...:User:hiringDate": "...") and normalizes it correctly — Entra isn't even sending that form.

The question

Is there a supported way to register a custom SCIM extension schema URN with Microsoft Entra customappsso such that the provisioning serializer emits its attributes onto the wire — either as nested envelopes per RFC 7643 §7, or as flat URN-prefixed top-level keys?

Specifically:

  1. Is the Edit attribute list for customappsso portal feature expected to make custom URN-prefixed attributes appear in the outbound JSON body, or is it understood that customappsso's serializer only emits attributes whose URN matches a hardcoded allow-list (core urn:ietf:params:scim:schemas:core:2.0:User plus the enterprise extension)?
  2. If custom URN extensions are supported, what's the correct schema shape? Do we need to add a separate object entry per URN under directories[customappsso].objects, modify the synchronization rule's targetObjectName, or use a different mechanism entirely?
  3. If custom URN extensions are not supported via customappsso, is this a documented limitation, and is there a tracked roadmap item / preview feature to add support?

We're trying to make a decision between investing further in the Graph schema PATCH path or documenting the limitation for our customers and recommending an alternative IdP. Either answer is usefu, and confirmation of a current limitation is just as valuable as a workaround.

I've also attached, for reference, screenshots of the configured attribute mapping table, the entries declared under Edit attribute list for customappsso covering the three URN-prefixed targets, and a Microsoft Graph response confirming that the source extension attributes (onPremisesExtensionAttributes.extensionAttribute1 and extensionAttribute2) are populated on the test user.Many thanks!

User's image

User's image

User's image

Microsoft Security | Microsoft Entra | Microsoft Entra External ID

1 answer

Sort by: Newest
Most helpful Newest Oldest
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.