Issue with Account-Entitlement Association based on Aggregation Order in ISC

[GovindSaini]

I’ve encountered some unexpected behavior regarding the order of aggregation operations in SailPoint ISC and wanted to see if others have experienced this or if this is expected behavior.

The Issue: I’m observing that the order in which aggregations are run affects whether accounts are correctly associated with their entitlements.

1. Account Aggregation First → Entitlement Aggregation: When I run Account Aggregation followed by Entitlement Aggregation, everything works as expected. Accounts and entitlements are created, and the accounts are correctly associated with their entitlements.

2. Entitlement Aggregation First → Account Aggregation: When I reverse the order (Entitlement Aggregation first, then Account Aggregation), both accounts and entitlements are created, but the accounts do not get associated with their entitlements.

Detailed Observation: It appears this issue stems from how the entitlement object is constructed during creation.

• When an entitlement is created via Account Aggregation (implicitly, because it came in with the user record), the entitlement object includes a property called attribute. This property seems to be the link that tells the entitlement which property on the user holds the entitlement data.

• When an entitlement is created via Entitlement Aggregation, this attribute property is missing from the entitlement object.

Consequently, if the entitlement is created first via Entitlement Aggregation (missing the attribute property), subsequent Account Aggregations fail to map the users to that entitlement because the link is missing.

Questions:

• Is this strict dependency on aggregation order (Account before Entitlement) expected behavior in ISC?

• Is there a configuration or workaround that ensures the attribute property is populated correctly regardless of which aggregation runs first?

[ts_fpatterson (Fred Patterson)]

Check out the below documentation. I’m assuming you are using the Web Services Connector.

Supported Operations (Web Services Connector) This page details the distinction between “Account Aggregation” (which links users to entitlements) and “Group Aggregation” (which fetches the entitlement objects). https://documentation.sailpoint.com/connectors/webservices/help/integrating_webservices/supported_operations.html

Response Mapping Configuration This section explains how to map API responses to schema attributes. This is where the attribute property is implicitly handled during account aggregation. Response Mapping

Managing Entitlements (General) General overview of how entitlements are aggregated and managed in ISC. Managing Entitlements - SailPoint Identity Services

Reverse Entitlement Aggregation & WSAO Rules - issue when entitlements are aggregated before accounts, and provides advanced workarounds (like using “After Operation Rules”) if you absolutely must reverse the order. Reverse entitlement aggregation for Web Services connector

Account Aggregation & Entitlement Correlation Discussions on how Account Aggregation is required to “promote” raw data into linked entitlements. Account aggregation right after operation

[GovindSaini]

Thanks for the references. I understand that Account Aggregation is typically responsible for linking users to entitlements, but my issue is specifically about the integrity of the entitlement object itself when it is created via Group/Entitlement Aggregation first.

Here is the specific scenario causing the failure:

1. I run Entitlement Aggregation. This pulls in entitlements that might not currently be assigned to any users (or before the users are aggregated).

2. Because these come in via the Entitlement operation, the attribute property on the entitlement object is not populated.

3. Later, when I run Account Aggregation, I pull in users who should have these entitlements.

4. The Critical Failure: Because the entitlement object already exists (from step 1) but is missing the attribute property, the Account Aggregation fails to link the user to the entitlement. It seems the connector cannot map the user’s data to an entitlement that lacks this property.

Basically, if an entitlement is created first without this property, it stays ‘broken’ and accounts never get mapped to it.

My specific question is: How do I explicitly configure or hardcode the attribute property during Entitlement Aggregation? I need to ensure that when I fetch entitlements (even those with no current users), they are created with the correct attribute value so that future Account Aggregations can successfully map users to them

[ts_fpatterson (Fred Patterson)]

What Schema and entitlement types do you have?

[lampard08 (Chelsea Blue)]

what you post your entitlement objects schema’s :

"identityAttribute", "displayAttribute":

[GovindSaini]

We only have a single type here’s the schema -

[
    {
        "type": "group",
        "displayAttribute": "Name",
        "identityAttribute": "Id",
        "attributes": [
            {
                "name": "Id",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "Name",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "DisplayName",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "Description",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "Email",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "MailEnabled",
                "type": "boolean",
                "description": "",
                "multi": false
            },
            {
                "name": "Type",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "Enabled",
                "type": "boolean",
                "description": "",
                "multi": false
            },
            {
                "name": "SecurityEnabled",
                "type": "boolean",
                "description": "",
                "multi": false
            },
            {
                "name": "SecurityIdentifier",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "AllowExternalSenders",
                "type": "boolean",
                "description": "",
                "multi": false
            },
            {
                "name": "Privileged",
                "type": "boolean",
                "description": "",
                "multi": false
            },
            {
                "name": "Owner",
                "type": "string",
                "description": "",
                "multi": false
            },
            {
                "name": "RiskScore",
                "type": "int",
                "description": "",
                "multi": false
            }
        ]
    }
]

[lampard08 (Chelsea Blue)]

and in your accounts schema, do you have the groups/entitlement type attribute mapped to id?

[GovindSaini]

Yes, in my account schema, the groups/entitlement-type attribute is correctly mapped to the entitlement’s ID property.

To clarify, when I run Account Aggregation first (so the entitlement data comes in as part of the accounts), the mapping works perfectly. Then, when I follow up with Entitlement Aggregation, everything continues to work as expected—the accounts and entitlements are properly associated.

The problem only occurs when I reverse the order and run Entitlement Aggregation first, as described in my previous message. In that case, the required mapping property (attribute) on the entitlement isn’t set, which breaks the account–entitlement association later on.

[EricPanico]

Have you tried adding a WebServiceAfterOperationRule? Have a look at this and let me know if you’ve considered this already.

Web Services After Operation Rule | SailPoint Developer Community

[David_Norris (Terry Yau)]

I have a gut feeling that your account aggregation response payload doesn’t have the account’s entitlement linkage details, and that your account<–>entitlement linkage is coming from your entitlement aggregation response.

[GovindSaini]

Thanks! Just to clarify—I am sending group/entitlement details as part of each account during account aggregation, so the linkage gets created before I even run entitlement aggregation. Is there a recommended way to structure the payload or perform aggregations to ensure the account<–>entitlement links are always set up correctly, regardless of the order? I’d like to make sure I’m doing this right. Any advice appreciated!

[GovindSaini]

I haven’t tried using a WebServiceAfterOperationRule yet—honestly, I’m not familiar with what these are or how they might help in this context. Could you explain a bit about how they work and how I might use one for this issue? Thanks!

[EricPanico]

I agree with @RandomUser4096 ‘s gut feeling here … so the response contains the link. The WebServiceAfterOperationRule should allow you to grab the response and perorm a modification on the data before it gets saved. Iterate through the list object (whether it’s one enetitlement or many, it’s still a list object), inspect the map in each object, find the attribute you want to modify, get the attribute and modify the record.

The reason you have to do this is when you run an entitlement aggregation its only looking at entitlements - it doesnt know how they will be linked. So, after you do the entitlement aggregation you have to provide this information back, so you’re telling ISC this is the account this entitlement will be linked to. The attribute property should be in the response object.

NOTE: the create connector rule has 2 api versions, one in beta and one in v2024

create-connector-rule | SailPoint Developer Community

I suggest you attempt creating the rule and let us know your result. I can’t find an example of anyone actually doing this, so if there is anyone out there that has tried this with success please post details.

By the way, I realize that we have been assuming that you are using a standard Web Services connector, not a custom SaaS connector. The SaaS connector framework is context aware by design, so you would not be having this issue with a custom SaaS connector. Also, it should be noted that if this does work, this rule needs to be developed, provided and supported by you as part of your official integration package. You should take all this into consideration.

[GovindSaini]

Thanks for clarifying! I’m actually using a custom SaaS connector, so I’m interested to know how this works out-of-the-box with the SaaS framework. Is the account<–>entitlement linkage handled automatically, or do I still need to implement something similar using connector rules? Any details about how context awareness simplifies this process would be really helpful.

[EricPanico]

Ah, well, ok … In the account schema definition, you should be including a “entitlement”: “true: and “schema”: “group” attributes. Linking will then be automatic. Unfortunatly, it seems to work without including this, so it’s not immediately apparent that this is a requirement.

[GovindSaini]

I wasn’t aware of the need for the “schema” property—thanks for pointing that out. I was already sending "entitlement": true, but after adding the "schema": "group" property

I am sending the entitlement property group in the response of account discover. I have added schema to it.

I’m still seeing the same issue: if I run entitlement aggregation first, the entitlements get created,

but when I aggregate accounts afterwards, the accounts aren’t mapped to the entitlements they’re part of.

Any other suggestions on what might be missing?

[vguleria (Vikas Guleria)]

Hi @GovindSaini

Most likely the issue with the account schema where the relation between the entitlements and accounts is not specified properly.
From the first look at your account schema here , I see in the schema attribute for group attribute is not properly defined.

Instead of string value of group, it should be a relation to your group schema, something like below

"name":"group",
"type":"string",
"entitlement":true,
"managed":true,
"multi":true,
schema”: {
            "type": "CONNECTOR_SCHEMA",

            "id": "{{id of the group schema}}",

            "name": "group"

        }
"description":"description"
     

This will then define proper relation between the entitlements you are reading from accounts and then ISC can identify them as group type of entitlements.

If you have multiple types of entitlements , then please make sure to link them account schema as well.

I hope this helps, please let me know if this works.

Regards
Vikas.

Hidden Text

Hidden Text

[GovindSaini]

Thanks for the suggestion! Unfortunately, the approach with the schema ID didn’t work for me—I couldn’t find an ID value for the group schema.

However, I did manage to fix the issue on my own by using "schemaObjectType" instead of schema. Once I added that property to properly link the account attribute to the entitlement type, the accounts started mapping to their entitlements correctly, regardless of aggregation order.

Appreciate the help!