I’ve created a Web Services Connector source and configured both Account Aggregation and Group Aggregation operations. The two operations use different API endpoints.
In the Account Schema, I’ve added an attribute (RoleId) for entitlements and configured it as:
Type: Group
Entitlement: Enabled
Multi-Valued: Enabled
The Group Schema contains OrgId and RoleId, with the RoleId attribute configured as the Entitlement ID and Entitlement Name.
I’ve also configured an After Operation Rule for Group Aggregation to build a custom entitlement using a prefix and subsequently map it to the account entitlement attribute.
The Group Aggregation API returns a response similar to:
{data=[{OrgId=Org, RoleId=Org_role}]}
The response mapping is configured as:
Root Path: $.data
OrgId → $.OrgId
RoleId → $.RoleId
Both OrgId and RoleId are included in the Group Schema.
When I run the Group Aggregation, the aggregation completes and shows that records were successfully scanned. However, the Entitlements page continues to display 0 entitlements.
Is there anything missing in the schema, response mapping, entitlement ID configuration, or aggregation setup that would prevent the scanned group records from being created and displayed as entitlements?
If the entitlement count is showing as successfully scanned during the Group Aggregation, but the entitlements are not immediately visible on the Entitlements page, it could potentially be a caching or UI refresh issue that may take some time to reflect.
One way to confirm whether the entitlement has actually been aggregated into ISC is to open a Role → Edit → Manage Access → Add Access and search for the entitlement by name. If the entitlement appears there, it confirms that the entitlement has been successfully aggregated into ISC and is just taking some time to appear on the Entitlements page.
I’ve faced a similar issue with a few connectors, where the entitlements took some time to reflect on the Entitlements page even though the aggregation was successful.
Hello Abhijit. @baoussounda’s suggestion looks correct. Since your Root Path is already $.data, try using RoleId and OrgId directly in the response mapping instead of $.RoleId and $.OrgId.
Thanks for your response. It looks like this may be a caching or UI refresh issue, as mentioned by Gopi S.
@Gopi2000 – I validated the entitlements using the approach you suggested: Role → Edit → Manage Access → Add Access, and I can see the newly aggregated entitlements there. However, they are still not visible on the Entitlements page.
Do you know how long it typically takes for the entitlements to appear on the Entitlements page? Is there any cache/index refresh that needs to be triggered, or should I just wait for the UI to synchronize?
Hello Abhijit. Did you get a chance to try @baoussounda’s suggestion by changing the response mappings to relative paths and running the aggregation again?
Yes, I tried updating the response mapping as suggested, but the Entitlements page still shows a count of 0, even though the aggregation completes successfully.
Since you can see the entitlements under Role > Manage Access > Add Access, it looks like the entitlement objects are being created successfully.
As one more check, could you try the List Entitlements API filtered by your source ID?
filters=source.id eq "your-source-id"
If the API also returns those entitlements, I would not make any further changes to the schema or response mapping.
Also, please clear any filters on Admin > Access Model > Entitlements and check again. If the API returns the entitlements but that page still shows 0, I would suggest raising a SailPoint Support case for the Entitlements page/display issue.
The List Entitlements API returns all the expected entitlements, so this appears to be a caching or UI refresh issue. I’ve opened a SailPoint Support ticket for further investigation.
