Share all details related to your problem, including any error messages you may have received.
Assign Entitlement Directly and Remove Entitlement from Business Role
We had set up Business Role 1 with Entitlement A.
However, we want to change to directly assign Entitlement A to the users of Business Role 1 and then remove the Entitlement A from Business Role 1.
We tried this, but get an error message saying the Entitlement A is already assigned to the user. We need to make these changes without the user losing any access. There are several hundred users that are impacted by these types of changes from Business Roles to Directly Assigned.
The Business Role has multiple entitlements (A, B, C, D, E, F, G).
But we want to pull Entitlement A out of the Business Role and assign it directly.
To prevent loss of access, we tried to Assign Entitlement A to the user, but it gives an error saying Entitlement A is already assigned to the user (it is via the Business Role).
If we remove Entitlement A from the Business Role, then the users will lose access until the Entitlement A is approved and applied to each user directly.
@dabrus
As the entitlement is assigned as part of the role, the granted by role flag is set to true. To achieve your use case, you need to remove the entitlement from the role, run the role change propagation and assign the entitlement directly.
Note: This will have a access related to issue, but you can plan it over a non working day.
So there is no way option to override the Entitlement Check?
Ie. Allow an Entitlement to be Added Directly first (essentially a duplicate entitlement). Then remove the Entitlement from the Role. This would eliminate any access outage for the user.
There is no direct way by which where user can have two set of entitlement.
Also, if the provisioning is enabled then there is no way you can directly add and remove entitlement without removing access.
To achieve it in ideal case you may stop provisioning then do the transition, but it will have a lot of change and failure points so practically should not be implemented.