8.5p1
We are facing an issue where during leaver the entitlements assigned to the user are filtered and not removed from user profile. This happens for both stand-alone entitlements and those entitlements that are part of a role. Also we see that the same entitlement is removed for one user but not for the other. This scenario happens during leaver.
If the same entitlement is removed for one user but not another, compare their account links and deprovisioning plans. This points to an identity/provisioning issue.
@lakshmipriya_n This looks more like an access assignment issue than an entitlement issue. Since the same entitlement is removed successfully for some users but not others, compare one working and one failing user to see how the access was originally assigned—directly, through a role, Access Profile, or another source.
Also check Provisioning Activity during the leaver event. If SailPoint is not generating a revoke request for the affected entitlement, then the issue is likely in the leaver/access-removal logic. If a revoke is generated successfully but the entitlement still remains, then check the target source and run aggregation to confirm the latest account state.
@Pankaj_IAM_SailPoint thanks for the response. If we take a case of one entitlement, it was assigned via role to both the users. And during the leaver, the access request to remove role is created successfully, but the entitlement in question is seen under filtered items for one user and revoked successfully for the other.
@ROHPU Thanks for your response. Are there any specific values which we need to compare for the users
You can compare the identity attributes, account links, role assignments, and the generated provisioning plan for both users. The difference should help identify why the entitlement is removed for one user but not the other.
@lakshmipriya_n Since the same entitlement is coming through the same role for both users, but SailPoint filters it for one user and revokes it for the other, I would check why SailPoint thinks the first user should still retain that entitlement.
The role-removal request is being generated correctly, so the leaver workflow itself seems to be working. The key is the Filtered Items details—check the reason shown there and compare the user’s other roles, access profiles, and existing assignments. There may be another assignment path causing SailPoint to consider that entitlement still required.
@lakshmipriya_n For the requests where it got filter out, please check the request xml in the debug. It’ll show the reason of filtering.. normally if something assigned via role, and if you try to remove entitltment directly, IIQ filters it out.. but there are other reasons as well.
Thanks all for suggestions. On further investigating, we found that the entitlement was first assigned to user as a separate entitlement, but later the entitlement was added to role. So, when role remove request is sent the entitlement is getting filtered (though the entitlement was part of the role). On further investigation we found a flag deassign entitlement to be set on the plan to cleanup all entitlement assignments. We are testing further with this flag set. Has anyone used this flag before?
As per analysis, the removal is working for the following scenarios when we set deassignentitlement flag as true in the plan.We had assignment=true earlier in the plan as well but that is not working.
1.Entitlement assigned directly to the user and later the entitlement got included in role.
2.Entitlement assigned directly to the user.
In both cases attribute assignment is there in identity and the same is being cleaned up as part of the initial step in leaver workflow but still the remove entitlement actions are getting filtered if we dont set deassign entitlement as true in the attribute request.Please let us know if anyone used this flag.
In IIQ 8.5p1, if entitlements are being filtered during leaver and not removed from the user profile, I would first check the provisioning plan before and after policy/plan filtering.
Key areas to validate:
Remove operations during leaver.ProvisioningPlanPlanCompilerProvisionerAlso, if the same entitlement is removed for one identity but not another, it usually indicates a difference in assignment source, role membership, account state, link data, or provisioning plan filtering logic rather than an issue with the entitlement itself.
Recommended next step: capture the generated provisioning plan XML for both users and compare the AccountRequest and AttributeRequest sections to identify where the remove operation is being dropped or filtered.
Hi Lakshmi,
The entitlement is filtered with the reason Dependency, which can occur for two reasons:
Regarding your point about the Leaver Event, since the removal plan is generated through a rule/script, could you please add the deassignEntitlement argument to all roles that are being removed through an AttributeRequest?
What this will do is add the preferRemoveOverRetain argument to the entitlement removal AttributeRequest. As a result, the entitlement removal request will not be filtered even if another operation creates a retain AttributeRequest for the same entitlement.
This ensures that, in cases where both retain and remove operations are generated for the same entitlement, the remove operation is always prioritized and the entitlement is successfully removed