Hi all 
Suppose I have entitlement X and entitlement Y in any application and an account already has entitlement X. Suppose they now request entitlement Y as well and this gets approved. Best practice would dictate that the account would now have access related to the entitlement X and have the access related to the entitlement Y. It would be strange if you lose access related to entitlement X if you have entitlements X and Y. And it would be strange that if you have entitlements X and Y, and you then lose entitlement Y, that you would suddenly gain more access instead of less.
This strange behavior is what happens when you use SailPoint’s user levels.
Suppose you have a birthright role, where everybody based on a certain identity attribute (like job function) will get the user level Source Subadmin. Then suppose that one of the identities with this role needs to be able to read all access profiles and segments for a week. Reading segments is only possible if you are an ORG ADMIN, so the user requests the ORG ADMIN user level through a different role with approval flow, which also gives access to read all access profiles.
However, once the ORG ADMIN user level was approved and provisioned, the identity was not able to read all access profiles. This is because besides the ORG ADMIN user level, the identity also still has the source subadmin user level and the combination yields unexpected results. Similarly if someone already is full ORG_ADMIN, you can limit their access, by adding the additional user level source subadmin. And if you then need to gain this access again, you need to lose this user level again. This looks like unexpected undesired behavior to me.
I think that losing User Levels to gain access should not be considered best practice.
SailPoint documentation mentions this to warn on this unexpected behavior:
Best Practice
Org Admin should not be assigned with any other elevated user level, such as Source Sub-Admin, Role Sub-Admin, or Helpdesk Admin. The Org Admin already has all rights enabled on all sources, and when assigned with other elevated user levels they can overlap in a way that may unintentionally curtail the Org Admin rights.
I would argue that this is not best practice, but instead is a workaround to a known bug.
In the situation where we have this role with birthright access, we now have to update the access to specify specifically “All users with a certain job function, except for the identity with uid …” each time we need to temporarily give someone ORG ADMIN access, to ensure they truly get all access related to this ORG ADMIN user level.
My recommendation for SailPoint would be to ensure that their user levels follow best practice. If one user level gives you access to only objects A1 and A2, while another user level gives you access to objects A1,A2,A3… and objects R1,R2,R3… then having both user levels should still give you access to A3. The access that you have should always be the sum of the access for each separate user level you have. So if an identity with ORG ADMIN and Source subadmin looks at the access profiles in the UI/API, the UI/API should know that all access profiles can be shown since the identity is ORG ADMIN.
Kind regards,
Angelo