Precedence Considerations

When an authorization decision is made, a permission condition is applied only if it is on the explicit control that is closest to the requesting user. Other conditions that are relevant because of further-removed group memberships don't provide additional, cumulative access.

If there is an identity precedence tie between multiple groups at the highest level of identity precedence, those tied conditions are combined in a Boolean OR expression (any row that meets either condition is returned). If the identity precedence tie includes an unconditional grant, access is not limited by any conditions.

The following table provides examples:

Precedence for Permission Conditions

Principle	Scenario	Outcome and Explanation
If there are multiple permission conditions that apply to a user because of the user's group memberships, then the highest precedence identity controls the outcome.	A filter on InformationMapA limits Read permission for GroupA. Another filter on InformationMapA limits Read permission for the SASUSERS group. The user is a member of both GroupA and SASUSERS.	The user can see only the rows that GroupA is permitted to see. GroupA has higher identity precedence than SASUSERS, so the filters that are assigned to GroupA define the user's access.
If there are multiple permission conditions at the highest level of identity precedence, then any data that is allowed by any of the tied conditions is returned.	A filter on InformationMapA limits Read permission for GroupA. Another filter on InformationMapA limits Read permission for GroupB. The user is a direct member of both GroupA and GroupB.	The user can see any row that is permitted for either GroupA or GroupB.
If there is a permission condition and an (unconditional) explicit grant at the highest level of identity precedence, then all data is returned.	A filter on InformationMapA limits Read permission for GroupA. An explicit grant on InformationMapA grants Read permission (unconditionally) for GroupB. The user is a direct member of both GroupA and GroupB.	The user can see all rows.

The following example describes the impact of identity precedence when a manager uses an information map that includes both of the following filters for a SALARY table:

A permission condition that is assigned to the SASUSERS group gives each user access to his or her own salary information.
A permission condition that is assigned to a Managers group enables each manager to see the salaries of the employees that he or she manages.

When the manager accesses the SALARY table, the filter that is assigned to the Managers group is applied and the filter that is assigned to SASUSERS is ignored. This is because the manager's direct membership in the Managers group has higher identity precedence than the manager's implicit membership in the SASUSERS group. To avoid a situation in which managers can see their employees' salaries but each manager can't see his or her own salary, you can use either of these approaches:

Assign the filters to two groups that have the same identity precedence. For example, if you assign the first filter to a general purpose user-defined group (rather than to SASUSERS), and you make each manager a direct member of that group, then managers will have an identity precedence tie between that group and the Managers group. This situation causes the two filters to be combined for members of the Managers group, enabling those users to see any row that is permitted by either filter.
Define the Managers filter in a way that encompasses all of the rows that the managers should be able to see. In other words, combine (OR together) the SASUSERS filter and the Managers filter.