SCIM Validator: Inconsistent roles[primary] Type Requirements — POST/list vs PATCH Operations

Question

We are implementing a SCIM 2.0 endpoint for Microsoft Entra ID user provisioning. The Microsoft Entra SCIM Compliance Validator is reporting two test failures due to inconsistent type expectations for the primary field in role objects.

Problem:

The validator expects the primary field to have different types depending on the operation:

POST + GET (list): roles[primary] must be string ("true" / "false")

• POST Create user returns: "primary": "true" ✅
  • GET /Users?filter=... returns: "primary": "true" ✅
    • Test: PASS
    PATCH + GET (list): roles[primary] must be boolean (true / false)

    - PATCH Update returns: `"primary": true` ✅
    
       - GET /Users?filter=userName eq "X" runs filter: `roles[primary eq true]`
    
          - Validator expects: `"primary": true` ✅
    
             - But GET endpoint returns: `"primary": "true"` (string)
    
                - Filter fails to match
    
                   - Test: **FAIL** (2 of 21 tests failing)
    

Root Cause:

The same list GET endpoint is called after both POST and PATCH operations. After POST, the validator expects string "primary"; after PATCH with a complex filter, the validator expects boolean primary. The validator logic appears to coerce the expected type based on the preceding operation, not on the SCIM specification.

What We've Tried:

1. Return primary as always string — POST test passes, PATCH test still fails
2. Return primary as always boolean — PATCH test passes, POST test fails
3. Dual-type serialization (string in some endpoints, boolean in others) — Same issue persists

Expected Behavior:

The SCIM specification (RFC 7643) does not mandate a specific type for multi-valued attribute properties like primary. However, the validator should accept one consistent type across all endpoints and operations, or the validator documentation should clearly specify the required type per operation.

Question for Microsoft:

Is this a known issue with the validator's type coercion logic? Should we use boolean, string, or is there a workaround to satisfy both test paths?We are implementing a SCIM 2.0 endpoint for Microsoft Entra ID user provisioning. The Microsoft Entra SCIM Compliance Validator is reporting two test failures due to inconsistent type expectations for the primary field in role objects.

Problem:

The validator expects the primary field to have different types depending on the operation:

POST + GET (list): roles[primary] must be string ("true" / "false")

• POST Create user returns: "primary": "true" ✅
  • GET /Users?filter=... returns: "primary": "true" ✅
    • Test: PASS
    PATCH + GET (list): roles[primary] must be boolean (true / false)

    - PATCH Update returns: `"primary": true` ✅
    
       - GET /Users?filter=userName eq "X" runs filter: `roles[primary eq true]`
    
          - Validator expects: `"primary": true` ✅
    
             - But GET endpoint returns: `"primary": "true"` (string)
    
                - Filter fails to match
    
                   - Test: **FAIL** (2 of 21 tests failing)
    

Root Cause:

The same list GET endpoint is called after both POST and PATCH operations. After POST, the validator expects string "primary"; after PATCH with a complex filter, the validator expects boolean primary. The validator logic appears to coerce the expected type based on the preceding operation, not on the SCIM specification.

What We've Tried:

1. Return primary as always string — POST test passes, PATCH test still fails
2. Return primary as always boolean — PATCH test passes, POST test fails
3. Dual-type serialization (string in some endpoints, boolean in others) — Same issue persists

Expected Behavior:

The SCIM specification (RFC 7643) does not mandate a specific type for multi-valued attribute properties like primary. However, the validator should accept one consistent type across all endpoints and operations, or the validator documentation should clearly specify the required type per operation.

Question for Microsoft:

Is this a known issue with the validator's type coercion logic? Should we use boolean, string, or is there a workaround to satisfy both test paths?

Answer 1

Treat roles[].primary as a JSON Boolean consistently; the string requirement is an acknowledged Microsoft Entra SCIM Validator bug, and Microsoft has not documented a workaround that reliably satisfies both contradictory test paths.^1^

Correct endpoint behavior

Return the same representation from POST, PATCH, direct GET, and filtered/list GET:

{
  "roles": [
    {
      "value": "admin",
      "display": "Administrator",
      "type": "application",
      "primary": true
    }
  ]
}

Also parse filter literals such as primary eq true as Boolean values, not strings. Do not switch serialization according to the preceding operation.

The fact that roles is multi-valued does not leave its subattributes untyped: the SCIM schema defines the types of properties within each complex value. Microsoft’s SCIM API examples likewise use an unquoted Boolean in complex-value filters—for example, primary eq true.^2^

How to handle the two failed validator tests

Since always-string, always-Boolean, and operation-dependent serialization have already been tested, there is no further endpoint representation demonstrated to satisfy both validator expectations. Record these two failures as validator exceptions:

1. Save the complete request/response trace for each failing test.
2. Include the validator test name and the contradictory expected/actual types.
3. Include your /Schemas declaration for roles.primary.
4. Demonstrate that every endpoint returns Boolean true or false.
5. Reference Microsoft’s accepted response acknowledging this specific string-versus-Boolean behavior as a validator bug.^1^

The validator documentation lists other known limitations but does not list a flag or configuration that changes roles.primary coercion.^3^ The general SCIM behavior flag documented by Microsoft changes specific PATCH scenarios such as active, single-valued strings, replacing multiple attributes, and removing group members; it does not document a fix for roles.primary.^4^

If this is for App Gallery onboarding

The Microsoft Entra SCIM Validator is a development tool, not the validation mechanism required for App Gallery publication. Microsoft directs gallery publishers to run the Azure Logic Apps validation template and submit those results instead.^3^

Therefore:

• Keep production behavior standards-compliant with Boolean primary.
• Do not introduce request-history-dependent output solely to make the validator pass.
• Submit the validation evidence with the two known contradictory failures and engage the product/onboarding team if those failures block submission.

---

References

1. in SCIM validator tool, in request, at attribute role the 'primary' value is string but should be boolean - Microsoft Q&A
2. Microsoft Entra ID SCIM API reference
3. Tutorial: Validate a SCIM endpoint
4. Known issues and resolutions with SCIM 2.0 protocol compliance of the Microsoft Entra user provisioning service