Due to certain business requirements, we have some use cases where the authoritative source will send us the updated data which fulfil the role criteria to provision the entitlement B and not the old entitlement A. Is there a way for the user to retain entitlement A while having the newly updated entitlement B as well? Understand that this can be done via access request, but is there a way to just do it via aggregation from authoritative source, eg: Before provisioning rule etc. ?
You can just remove the Access Profile from the role which has Entitlement A, that would help you to retain the old Entitlement and then make the changes for the newly updated requirements. This will help you to retain the previous access.
Let’s say that user has Department: Test Dept1, Which granted Entitlement A
Later, user moved to Test Dept2 which might grant Entitlement B
As department condition won’t satisfy for Entitlement A, user will loose. But you would like to retain it. Now user will have both Entitlement A and Entitlement B, Something like sticky entitlements.
So your Role should do Add only operation based on conditions but should not remove the Access.
If this is what your requirement then you can try using Workflows. We can add a Group/Entitlement based on some condition. But it won’t remove when the conditions changes.
I’m assuming this is the use case also and we had to something similar. In our case, we added an extra identity attribute to track an expiration date and recalculated this on a regular basis. It was related to a couple of Azure licensing groups so limited in scope and each role then had 2 conditions (the original conditions OR expiration date not expired to retain the access for a few weeks). Hard to explain, but hopefully the concept makes sense.
Yes, you have some pre-defined conditions to retain the access, so it was kinda straight forward. But for the current requirement @sjoyee asked, I don’t think he has conditions. Just retain the access that was assigned before, it is interesting for me to see the business use case.
I’m guessing your prior example is most likely (i.e. change in department, position, or similar) and there’s nothing simple to accommodate retaining access for the prior condition by design.
Ya we need to get some more insights from the requirement.
But however, if user needs to get a Role/AP/Entitlement based on some conditions and should not be removed even if there are changes in attributes used for condition then we can use Workflow rite ?