Hi Team,
I have a use case where there is an application for which i need to assign BR entitlement if the user has a couple of identity attributes as .
dataok as Y and is Manager as True.
The issue is this app only allows user to have one role at time a time.
so consider a new user gets his br access but then request for new that gets assigned and br ent is removed.
The issue is now the rule again processes the identity and re assign the br role removing the new one i just requested.
If it’s 1, and only 1, entitlement allowed then you need to duplicate all the roles you’re using with 2 versions.
Honestly - Allowing only a single entitlement to be assigned is generally not a good approach because of the “bloat” caused by all the unique combinations needed for these small additional entitlement sets.
I was thinking of replying until I thought “but what if there are like 10 available entitlements?” And thinking of all the “entitlements in source x does not equal” all the other 9 entitlements conditions you’d have to put in the role.
I know that salesforce only allows a user to be assigned a single profile at a time (which is an entitlement) but I never really had to deal with roles trying to assign a different profile
We have run into similar challenges with licensing related groups. Multiple groups that grant different license levels, but users should only have one to make them easier to count and avoid duplicate licensing, but everyone needs an initial one by default/birthright. One approach that worked for us is to update the role assignment criteria to exclude identities that have one of the other non-birthright groups.
Something like this:
This way when a user gets added to the new access/entitlement, they no longer meet the role criteria and IDN won’t try to provision the role related access back to the user. The small catch is that this role would have to be standalone for this application, as if it provisions other birthright access for other sources, you probably wouldn’t want that to be removed also.
Please let me know if this helps!
I agree with @zachm117 's solution to exclude the conflicting access in your birthright role logic. If set up properly, the original birthright role should not be reassigned.
