RLS Override

Hi,  you are already using the correct and recommended pattern for hierarchical Row-Level Security (RLS) in Power BI with PATHCONTAINS() and USERPRINCIPALNAME(). There is no need to replace or disable this logic in order to allow specific users to see all data.
What can work in this case is to add an override condition to the existing RLS rule, while keeping the current hierarchy behaviour unchanged for all other users. You can extend the existing rule by adding a condition that returns full access for specific users.
This approach is suitable when:

Only a small number of users require full access
The requirement is occasional or temporary

However, this solution does not scale well and requires manual updates to the DAX.

Hi lherbert501 

Yes, the overall approach is valid.

If you want certain users to occasionally see all data, the usual solution is not to bypass RLS from the report, but to extend the existing RLS design so it supports approved exceptions.

A small override table can work well for that. The idea is:
if the current user appears in the override table, return full access;
otherwise apply the normal hierarchy-based rule.

The main thing to watch is that the value checked in PATHCONTAINS must match the value stored in the path. For example, if your path is built from employee IDs or manager IDs, then checking USERPRINCIPALNAME() directly in PATHCONTAINS will not be enough on its own. In that case, you would need a proper mapping between the user login and the employee key used in the hierarchy.

Also, returning TRUE() in the RLS rule does not “disable RLS everywhere” by itself. It simply means that this table is not being filtered for that user, so it only works as expected if the model relationships propagate the filter correctly.

So yes, the override-table pattern is a reasonable option, but the exact DAX depends on how your hierarchy path is built and how the user identity is mapped in the model.

If the number of exception users is small and changes rarely, this can be a practical solution. If access changes often, managing it through a security table or group-based process is usually more maintainable.
If this post helps, then please consider Accepting it as the solution to help the other members find it more quickly