Question about single-value entitlement schema behavior in SailPoint ISC

[jwshin (Jaewon Shin)]

Hello SailPoint Community,

I have a question regarding the behavior of single-value entitlement schemas in SailPoint Identity Security Cloud.

Scenario:

• Source account schema and entitlement schema are both defined as single-value attributes.

• Account A currently has Entitlement 1 assigned.

• A request is made to assign Entitlement 2 to the same account.

• Each entitlement is linked 1-to-1 with an Access Profile.

Questions:

1. In this case, does SailPoint treat the request as a replacement, meaning Entitlement 1 is removed and Entitlement 2 is added?

2. After Entitlement 2 is successfully provisioned, will Identity Refresh keep it stable, or could there be repeated provisioning attempts (e.g., flipping between Entitlement 1 and Entitlement 2) depending on how the source reports the entitlements?

3. Since the structure is 1 entitlement = 1 access profile, when Identity Refresh runs, does SailPoint try to replace the access profile (switching back and forth), or is the new assignment considered stable and fixed?

4. Is there any official documentation or best practice that explains how ISC handles single-value entitlement assignment in this scenario?

I would appreciate any clarification or reference to documentation.

• Replacement Behavior (Entitlement Switch)
• Repeated Flipping (Back-and-Forth Changes)
• Dual Assignment Attempt (Error Case)
• Access Profile Stable Assignment
• Other (Please share your experience)

Thanks in advance!

[j_place (Jeremy Place)]

Hi @jwshin Please see the following post, particularly @jesvin90 solution which explains that Access Profile requests are not “sticky”

Modifying a Single valued entitlement

I have a JDBC source for which i have written the provisioning rule as per the below example. I want to know if the modify operation mention in this example is for a single valued entitlement or a multivalued entitlement? When i send a modifying access request for my single valued entitlement it modifies the entitlement using the update query but an identity refresh tries to reset it back to the old value. My question is old entitlement automatically revoked or i need to do a revoke request …

[jwshin (Jaewon Shin)]

Hi @j_place ,

Thank you for sharing your insight!
I tested this scenario in our customer’s sandbox tenant, and Access Profiles 1 was successfully changed to Access Profiles 2 (with the provisioning rule configured to properly update the entitlement).
As mentioned in the link, Access Profiles are indeed less “sticky” compared to entitlements.

Thanks again!