Hi community,
I was recently going through this post : Role Entitlement Removal while doing some poc.
Now I have a very basic question, please feel free to reply if my understanding it correct:
If you create a role with ENT-1, but USER-1 does not match the role criteria so role is never assigned, and the ENT-1 access was granted directly through the target application to USER-1 long time back before creating the role. Now as there is a role and no criteria match on USER-1 but ENT-1 will remain assigned to USER-1 as entitlement and will still appear in the Entitlements section, and will not be removed from USER-1.
I’m no expert, but maybe a search query for identities with accounts on source name, which have the entitlement assigned, but are not a member of the role.
Then you could create a certification, to check if the entitlement is still required, and if not I presume that it would remove the entitlement.
I’m not too sure what the query would be, but that could be a logic to find it?
Hope this helps.
I also think that the entitlement will not be removed, because they never had the role. If they had the role, and then if the role would be removed, then the remove entitlement operation would be triggered.
If a user has an entitlement and you then create a role to assign that entitlement to users, ISC will not remove that entitlement from users that do not meet that role criteria. ISC roles only remove access from users if they meet the role criteria then the users are updated and no longer meet the role criteria, if the role was requested then later revoked, or if you have role propagation on and remove the entitlement/access profile from the role.
My post you linked is from when they initially added support for adding entitlement to roles and there was some buggy behavior initially. In my case, we users had an entitlement, we then created a role that the users did match the criteria for, they later were updated and no longer matched the criteria, but the access was not getting removed as we had expected. This is no longer the case and is a slightly different scenario than what I believe you are asking about.
In your example, USER-1 already has ENT-1 directly from the target application. Since USER-1 never matched the role criteria, the role was never assigned to the user.
So even though the new role also contains ENT-1, ISC does not remove the existing entitlement from USER-1. There is no role assignment to remove because USER-1 never had that role in the first place.
If USER-1 later meets the criteria and gets the role, normal role assignment behavior applies. If the user later stops meeting the criteria and the role is removed, ISC deprovisions the access assigned by that role unless the same access is also assigned through another role (Managing Roles).
If your goal is to find users who already have ENT-1 directly but should no longer have it, a search-based Access Item certification is one option. You can target ENT-1 as a standalone entitlement and review or revoke it for identities holding it as standalone access (Starting a Campaign from Search).
Correct me if I understood your question: User 1 is assigned an Ent 1 via Access Request/Aggregation but that Ent 1 is also a part of criteria based Role 1. But User 1 never meets the criteria and was never assigned a Role 1.
So, will the entitlement be removed or not via Cert or Access Request based Revoke right ?
We have this on my agenda for Navigate 2026 to cover in my breakout session.
So, below is what will happen, its different for both Cert based revoke and a normal access request revoke:
Access Request Based Revoke: As User 1 never had Role 1, so you only have 2 options either set a Sunset date and the entitlement will get revoked once the sunset date arrives. As Ent 1 was never encapsulated, hence Role 1 is not in the picture.
Other option being from UI/API you trigger a revoke request, again for the Ent 1 directly as it was never encapsulated.
Certification based Revoke:
If you launched a Ent based Certification, the said Ent will show up individualised as it was never encapsulated as Role 1 was never assigned. And you can choose to revoke.
If you launched a Role based Certification, then as this is not assigned to you via Role 1 neither do you have Role 1, so this Ent 1 will not show up on your cert. And hence cant trigger a revoke.
But on this case by any chance you had Role 1, and as Ent 1 is part of Role 1, no matter how you got it, certification will revoke it with Role 1, even if you wanted it to stay.
Similar situation if done via Access Request revoke on Role 1, if you have Role 1, but Ent 1 was not provisioned via Role 1, in this case Only Role 1 is dropped and Ent 1 is retained.
I know I went overboard then your question, but its worth having this clarity in the back of your mind.