# Need recommendations for removing sticky access for termed users

**URL:** <https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660>\
**Category:** SHF Discussion and Questions\
**Tags:** connectors, provisioning, access-requests, workflows, apis, identity-security-cloud, entitlements\
**Created:** [September 28, 2025, 1:07am UTC](https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660 "2025-09-28T01:07:10Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Prashanth1812](https://avatars.discourse-cdn.com/v4/letter/p/41988e/32.png) [@Prashanth1812](https://developer.sailpoint.com/discuss/u/Prashanth1812)\
**Post date:** [September 28, 2025, 1:07am UTC](https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660/1 "2025-09-28T01:07:10Z")

</div>

Hi All,

Need help if you ran into this scenario, TIA

Scenario:

ISC is adding back access to a termed user thru identity refresh even after most of the access are being revoked automatically and adding old entitlements back which were once added through API request.

Note: I have enabled remove all access from UI. Also, we have a before provisioning rule in place to remove all access if LCS = inactive.

---

<div class="post-metadata">

**Author:** ![Jetendrakumar1991](https://avatars.discourse-cdn.com/v4/letter/j/839c29/32.png) [@Jetendrakumar1991](https://developer.sailpoint.com/discuss/u/Jetendrakumar1991)\
**Post date:** [September 28, 2025, 8:48am UTC](https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660/2 "2025-09-28T08:48:53Z")

</div>

Hi @Prashanth1812 , you can read below blog & i am sure, you will get your solution.

> [@Workflow to remove ALL leavers' standing access](https://developer.sailpoint.com/discuss/t/workflow-to-remove-all-leavers-standing-access/13025):
>
> Hi everyone, This workflow auto-revokes any standing access leavers have either through a micro targeted access certifications or by leveraging revoke access requests after being terminated. This should ensure that all leavers’ access is removed upon terminated and not just access assigned through birthright roles. Additionally, an audit trail is generated to document when and why the access was removed. This workflow was designed and built with the help and input of a multiple people! Thank…

---

<div class="post-metadata">

**Author:** ![UjjwalJain](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/ujjwaljain/32/24704_2.png) [@UjjwalJain](https://developer.sailpoint.com/discuss/u/UjjwalJain)\
**Post date:** [September 28, 2025, 9:46am UTC](https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660/3 "2025-09-28T09:46:58Z")

</div>

Hi @Prashanth1812,

You can make use of workflows to raise an access revoke request and remove all of the user’s access.

---

<div class="post-metadata">

**Author:** ![iamnithesh](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/iamnithesh/32/42445_2.png) [@iamnithesh](https://developer.sailpoint.com/discuss/u/iamnithesh)\
**Post date:** [September 28, 2025, 1:05pm UTC](https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660/4 "2025-09-28T13:05:58Z")

</div>

> [@Prashanth1812](#):
>
> we have a before provisioning rule

Inside your BP rule, add this to each of the Remove Entitlement Attribute Requests

```auto
attributeRequest.put("assignment", true);

```

---

<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 27, 2025, 1:06pm UTC](https://developer.sailpoint.com/discuss/t/need-recommendations-for-removing-sticky-access-for-termed-users/183660/5 "2025-11-27T13:06:57Z")

</div>

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