# Attribute assigmment / identityEntitlement not getting after remove Access wf

**URL:** <https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149>\
**Category:** IIQ Discussion and Questions\
**Tags:** identityiq, workflows\
**Created:** [July 23, 2026, 1:27pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149 "2026-07-23T13:27:31Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![aakashpandita](https://avatars.discourse-cdn.com/v4/letter/a/71e660/32.png) [@aakashpandita](https://developer.sailpoint.com/discuss/u/aakashpandita)\
**Post date:** [July 23, 2026, 1:27pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149/1 "2026-07-23T13:27:31Z")

</div>

I have written a custom wf where i am creating a plan to remove access for a user. Inside the wf i am using the 3 default ootb steps of LCM wfs which is - Identity Request Initialize, Identity Request Provision, Identity Request Finalize.  
Once the wf runs, the access request gets completed and successful marked with green but in actual the AttributeAssigmment / identityEntitlement are not getting removed which shows as an exclamation sign on UI of identity and when we run refresh obviously IIQ is re-provisioning the entitlement.  
My question is - is ther any separate step i need to configure to get rid of the entitlement completely, i mean everything related to Entitlement should be removed and it should not get re-provisioned  
Below is the plan created :

```auto
<ProvisioningPlan nativeIdentity=" ****" targetIntegration="Active Directory" trackingId="">
  <AccountRequest application="Active Directory" nativeIdentity="CN=Aaka***" op="Modify">
    <Attributes>
      <Map>
        <entry key="flow" value="AccessRequest"/>
        <entry key="interface" value="LCM"/>
        <entry key="operation" value="EntitlementRemove"/>
      </Map>
    </Attributes>
    <AttributeRequest name="memberOf" op="Remove" value="CN=OKT***"/>
  </AccountRequest>
  <Attributes>
    <Map>
      <entry key="comments" value="qa"/>
      <entry key="identityRequestId" value="000024"/>
      <entry key="requester" value=" ****"/>
      <entry key="source" value="LCM"/>
    </Map>
  </Attributes>
  <Requesters>
    <Reference class="sailpoint.object.Identity" id="" name="***"/>
  </Requesters>
</ProvisioningPlan>

```

---

<div class="post-metadata">

**Author:** ![patrickboston](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/patrickboston/32/5876_2.png) [@patrickboston](https://developer.sailpoint.com/discuss/u/patrickboston)\
**Post date:** [July 23, 2026, 3:26pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149/2 "2026-07-23T15:26:45Z")

</div>

You need to set the assignment argument on the `AttributeRequest` to ensure the `AttributeAssignment` gets removed. Add this to your code that generates the `AttributeRequest`.

```java
attrReq.put("assignment", "true");

```

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 23, 2026, 4:47pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149/3 "2026-07-23T16:47:10Z")

</div>

Hello Aakash. @patrickboston is right, the `assignment` flag is what you need here.

The group is removed from AD, but without this flag, IIQ retains the sticky AttributeAssignment on the identity. When Identity Refresh runs with “Provision assignments” enabled, IIQ sees that the assigned entitlement is missing from the account and provisions it again. The exclamation mark is consistent with that mismatch. Add the flag when building the removal request:

```auto
attrReq.setAssignment(true);

```

The plan XML should then include:

```auto
<entry key="assignment" value="true"/>

```

This allows IIQ to remove the AttributeAssignment along with the entitlement. No separate cleanup should normally be required. If the IdentityEntitlement remains temporarily, aggregate the account and refresh the identity to reconcile it.

---

<div class="post-metadata">

**Author:** ![patrickboston](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/patrickboston/32/5876_2.png) [@patrickboston](https://developer.sailpoint.com/discuss/u/patrickboston)\
**Post date:** [July 23, 2026, 5:36pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149/4 "2026-07-23T17:36:17Z")

</div>

@punna0001 hey you copied my answer 😫

---

<div class="post-metadata">

**Author:** ![punna0001](https://sea1.discourse-cdn.com/sailpoint/discuss/user_avatar/developer.sailpoint.com/punna0001/32/42011_2.png) [@punna0001](https://developer.sailpoint.com/discuss/u/punna0001)\
**Post date:** [July 23, 2026, 6:12pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149/5 "2026-07-23T18:12:10Z")

</div>

> [@punna0001](#):
>
> Hello Aakash. @patrickboston is right, the `assignment` flag is what you need here.

Not at all, Patrick 🙂 You may have missed the first line where I acknowledged that your answer was correct. I only added a little more context around it. Full credit to you for pointing out the `assignment` flag. We are on the same team here 🤝

---

<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:** [September 21, 2026, 6:12pm UTC](https://developer.sailpoint.com/discuss/t/attribute-assigmment-identityentitlement-not-getting-after-remove-access-wf/217149/6 "2026-09-21T18:12:17Z")

</div>

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