and more in a single search tool across platforms. Read the announcement here. |
10/25/2023 01:02 PM - edited 10/25/2023 01:03 PM
Is it normal that when we remove an entitlement through an ARS request, both the entitlement and its mapped entitlements peers are staged for removal, but doing the same via the UI + triggering Technical Rule's "Remove Birthright Access if condition fails" retains the the mapped entitlements?
---
For context, we have a technical rule that assigns an entitlement based on the user's department + role. A subset of departments have a secondary entitlement tied to these department entitlements which are being added via entitlement mappings.
When an ARS request is made to remove their department entitlement, both the department entitlement and the mapped entitlement are staged for removal.
However, if we modify the user from the UI and trigger the technical rule via a User Update rule, the technical rule's "Remove Birthright Access if condition fails" removes only the department entitlement. The corresponding mapped entitlement stays on the account.
Is this expected behavior, and is there a recommended work-around? I understand we could duplicate the entitlement map as if-else technical rule logic, but this seems unnecessarily over complicated and difficult to maintain.
10/25/2023 07:14 PM
under Entitlement type "Exclude Entitlements Assigned via Rule while Request" option is enabled ?
10/26/2023 05:40 AM
Yes; it is currently on.
To clarify, desired behavior is that the technical rule will cause the mapped entitlement to get removed too.
10/30/2023 01:46 AM
Hi @alanbixby
The default behavior is as mentioned below.
All the access provisioned via that rule only will be removed if you select Remove Birthright Access if the condition fails option.
Reference:
Creating Technical Rules (saviyntcloud.com)
Regards,
Dhruv Sharma