Below is the …/Group response when attempting to retrieve it via Postman:
Hi @rmndepns
Group aggregation appears to be successful. I would verify that the account endpoint is returning the group membership attribute and that the attribute is configured as a multi-valued entitlement attribute in the account schema. Also, ensure the group values in the account response match the entitlement IDs and rerun Entitlement Aggregation followed by Account Aggregation.
If the entitlement attribute was marked in the schema after the initial aggregation, that could be causing this behavior. Please rerun Entitlement Aggregation followed by Account Aggregation and check if the entitlement assignments appear correctly.
Hello Reymond,
I would check the /Users response for that same user, not only the /Groups response.
From what you shared, group aggregation looks okay, meaning ISC is able to bring the group object. But for the entitlement to show under the account, ISC also needs to see that group membership on the account/user side during account aggregation. Try calling that specific user in Postman and check if the response has something like this:
"groups": [
{
"value": "group-id-here",
"display": "Admin"
}
]
The value is the important part. It should match the group ID that was already aggregated as the entitlement. If groups is missing or empty in the /Users response, then ISC has the group object, but it cannot link that group back to the account. That would explain why the entitlement is blank on the account.
Also check the account schema once. The attribute holding group membership should be multi-valued, marked as an entitlement, and linked to the Group entitlement schema/type. If the SCIM response returns groups but the account schema or JSON path is mapped as group, it will not populate correctly.
After correcting it, I would run it in this order: