# Webservices Add Entitlement by Requesting keeps on reprovisioning and created Identity refresh activities

**URL:** <https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016>\
**Category:** SHF Discussion and Questions\
**Tags:** webservice-connector, provisioning, identity-security-cloud, entitlements\
**Created:** [September 12, 2024, 2:02pm UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016 "2024-09-12T14:02:23Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![neeraj99](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/neeraj99/32/14001_2.png) [@neeraj99](https://developer.sailpoint.com/discuss/u/neeraj99)\
**Post date:** [September 12, 2024, 2:02pm UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016/1 "2024-09-12T14:02:24Z")

</div>

Hi all,

I have a webservices connector which is configured with Add Entitlement operation.

I have a requirement where the entitlements should be requestable (I have a freedom to create Access Profile/ Role) but for the sake of testing, we have marked entitlements as requestable and think it can be the way going forward for few other accesses.

So when i try to request different accesses through Request center basically (entitlements) there are a lot of identity refresh entries in account activity which corresponds to Modify account.  
Now i am not sure why is it happening but i can see that on those refresh activities i can see my access items being listed there whichever i have been requesting.  
So if i had requested A,B,C,D,E,F earlier and now i am requesting G then i can see entries being made as Add access A,B,C,D,E,F,G and it is not just once but if there are 7 access in total then 7 identity refresh activities are there.

My end goal was to add only one access at a time. and i am able to do that by adding an Before Operation rule on Add Entitlement operation.  
But the main issue is that on UI it is giving me all the accesses until i aggregate the account again and if i aggregate then again the Modify operation is being made to add the other accesses. So need inputs on how can i remove those identity refresh (Modify) activities and make sure only 1 access is provisioned at a time.

Your inputs are valuable thanks in advance 🙂

---

<div class="post-metadata">

**Author:** ![shekhardas1825](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/shekhardas1825/32/20889_2.png) [@shekhardas1825](https://developer.sailpoint.com/discuss/u/shekhardas1825)\
**Post date:** [September 12, 2024, 5:12pm UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016/2 "2024-09-12T17:12:49Z")

</div>

@neeraj99 Did you check whether the account on sailpoint has the requested entitlement intact before and after aggregation?

Did you check if the entitlement is provisioned to the target and getting aggregated back to the source?

Because entitlements are sticky in nature as you mentioned you have requested through request center if it finds that if any moment the entitlement is removed in target then it’s going to provision again.

If you remove it from certification or Manager removes that entitlement it wont reassign.

You won’t see this behaviour if you use Access Profiles.

---

<div class="post-metadata">

**Author:** ![neeraj99](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/neeraj99/32/14001_2.png) [@neeraj99](https://developer.sailpoint.com/discuss/u/neeraj99)\
**Post date:** [September 13, 2024, 4:05am UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016/3 "2024-09-13T04:05:51Z")

</div>

> [@shekhardas1825](#):
>
> nds that if any moment the entitlement is removed in target then it’s going to provision again.
> 
> If you remove it from certification or Manager removes that entitlement it won

Yeah i verified it after req. the ent is added in the UI page, so i would see 3,4 entitlements there which i had req. previously.  
Now once i do the aggregation, one entitlement comes in as the downstream application accepts only one at a time. But as soon as the aggr. completes a lot of identity refreshes are triggered and i can see on target system, access being changed everytime from A-\>B-\>C…  
#2, So basically our usecase is simply a user can change the profile frequently and it is not a viable optn to use certification for removal of Entitlements.  
#3, Yes i tried with Access Profiles it works fine when i have AP like one activity only no un-necessary Identity refreshes etc.

I think i’ll have to go with Access profiles only. But if there’s any way we can stop these ent. being sticky on user would be a lot helpful.

Thanks for the quick response 🙂 Appreciate it.

---

<div class="post-metadata">

**Author:** ![shekhardas1825](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/shekhardas1825/32/20889_2.png) [@shekhardas1825](https://developer.sailpoint.com/discuss/u/shekhardas1825)\
**Post date:** [September 13, 2024, 4:38am UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016/4 "2024-09-13T04:38:31Z")

</div>

@neeraj99 at this moment seems like Access Profile is the good option.

But if you want to go with entitlement only then you may use of before provisioning rule to remove these entitlement or even explore workflows.

You definitely need to let IDN know that the previously requested entitlements (from request center) are removed from SailPoint. Otherwise as you mentioned as per your requirement you kind of replacing old entitlement to newly requested one using beforeOperation rule, when you aggregate the account SailPoint observes that previously request entitlement is not intact and since you did not remove it from SailPoint it will retry in every identity refresh as entitlements are sticky in nature.

Please read the “Revoking Requested Entitlement” Section

[Managing Requests for Entitlements - SailPoint Identity Services](https://documentation.sailpoint.com/saas/help/requests/config_entitlements.html)

---

<div class="post-metadata">

**Author:** ![jrossicare](https://avatars.discourse-cdn.com/v4/letter/j/a698b9/32.png) [@jrossicare](https://developer.sailpoint.com/discuss/u/jrossicare)\
**Post date:** [September 13, 2024, 5:34am UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016/5 "2024-09-13T05:34:31Z")

</div>

Does this relate to the ‘sticky’ entitlements issue that people are having?

See Idea: [Flag to allow customers to turn off | SailPoint Ideas Portal](https://ideas.sailpoint.com/ideas/GOV-I-3745)

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/sailpoint/original/2X/f/f2136700ed5e3703e0b85e02f6be799dacca7735.png) [@system](https://developer.sailpoint.com/discuss/u/system)\
**Post date:** [November 12, 2024, 5:34am UTC](https://developer.sailpoint.com/discuss/t/webservices-add-entitlement-by-requesting-keeps-on-reprovisioning-and-created-identity-refresh-activities/81016/6 "2024-11-12T05:34:56Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
