I’m currently working on a WebServicesconnector.
During account creation, everything works as expected — the default attribute value (for example, entitlement=Entitlement1) is correctly sent to the target system.
However, when I assign another Access Profile via Access Request Center that should change the entitlement value to Entitlement2 the events on the identity shows an “Add Entitlement Passed” event, but the request still sends the same value as during account creation (the default one as the one on the birthright role : Entitlement1).
So the Add Entitlement operation runs, but it doesn’t seem to take into account the entitlement value from the Access Profile that was requested..
Do you guys have any idea on how to solve this please?
Did you try to grant via access request Entitlement2 directly, on the identity which already has Entitlement1? If that’s successful, identity should have both Entitlement1 and Entitlement2 granted, correct?
If that works, you could try delete and re-create the access profile granting Entitlement2, revoke the Entitlement2 from the SailPoint, and try to grant AP containing Entitlement2 again.
@torry_salamat A few things come to mind that might help troubleshoot this:
Review the “Add Entitlement” operation in the source configuration. Make sure the context URL and HTTP method (usually PUT or POST) are correctly set. Also double check the API body and status code mappings. The body should dynamically reference the entitlement attribute using the placeholder syntax like $plan.<entitlementAttributeNameFromAccountSchema>$ which ensures it’s pulling the right value from the provisioning plan.
Schema configuration check: In the account schema for the source, verify that the entitlement attribute is defined as type "Entitlement" and marked as "Multivalued" if the system supports multiple entitlements per user. If it’s not set this way, SailPoint might not handle updates as expected.
Test outside of SailPoint ISC: Try assigning Entitlement2 directly via Postman or another API client. This helps confirm whether the target system accepts both entitlements and reflects them properly on the user’s account. It’s a good way to isolate whether the issue is within SailPoint or on the target side.
In fact, the entitlement on the target application is not multivalued. The API only accepts one single value, not multiple.
So, when we want to update the entitlement directly through the API, we must use a PUT operation with a payload like:
{ “attribute_entitlement”: “Entitlement2” }
Entitlement1 should get overwritten and replaced by Entitlement2..
However, in my provisioning events I’m seeing something unexpected:
I correctly see the Add Entitlement operation for Entitlement2.
But immediately after, I also see another Add Entitlement request for Entitlement1.
This happens because Entitlement1 is linked to a birthright role, and this birthright role is automatically assigned when the identity enters the Active state.
As a result, the system keeps re-adding Entitlement1 even when we are trying to replace it with Entitlement2.
Hi @torry_salamat I would remove Entitlement1 from the Birthright role as it is not part of a Birthright role, it is simply the “starting value” for that Entitlement. As such, I would add the attribute value to the create account policy (or to a provisioning policy associated with account enable), and optionally create a suitable (non-requestable, I assume) Access Profile for it if necessary for reporting purposes (Roles are “sticky”, APs are not).
Entitlement1 is only needed to create the account, as you mentioned.
My requirement is that the account should be created automatically when the identity’s status becomes Active.
But how can I trigger account creation without putting the entitlement in a role or in an Access Profile and without using a workflow..?
I removed the birthright role and placed Entitlement1 inside an Access Profile, then linked that Access Profile to the Identity Profile associated with the Active lifecycle state.
But the stickiness issue still happens when the identity is still in active state and i try to request another Access profile containing another Entitlement.
Hi @torry_salamat Apols, I didn’t appreciate this was the only Entitlement.
I can see 2 options, based on how many possible values you could have for that Entitlement attribute.
If many, is there any attribute in the target source schema which can be used as a “Dummy” Entitlement, eg. Description or Status or Extension-type attributes?
(Not tested) If not many, update your “Birthright” Role criteria to include the condition that entitlement does not equal “Entitlement2” AND any other values. Admittedly, this will leave “default” accounts with an Application Role (and associated AP) and updated accounts with an AP and no Role.
Hi @davidtrn I could be wrong, but it is my understanding that lifecycle states can only be used to enable, disable and delete accounts, not create accounts. IIRC SailPoint ISC requires some access assigned to an identity to create an account.
