RLS Override

[lherbert501]

Hi,

I have been using the PATHCONTAINS and USERPRINCIPAL model for user and manager hierarchy which works great for RLS, similar to the link below but the user and manager id's set up against each other

power bi rls hierarchy - Google Search

My question is, is there a way to overide this function in place that's working perfectly? I have some scenarios where I will need to enable a user to see all upon request, and didn't know if there was something I could do or put in place.

Thanks

[Zanqueta · Accepted solution]

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.

My suggestion is to create a small security table containing users who should bypass RLS (for example, executives).

The RLS logic then checks whether the current user exists in this table. If so, all rows are visible; otherwise, the hierarchy-based rule applies

VAR IsSuperUser =

    USERPRINCIPALNAME()

        IN VALUES ( RLS_Override[Email] )

RETURN

IF (

    IsSuperUser,

    TRUE(),

    PATHCONTAINS ( 'Employee'[Path], USERPRINCIPALNAME() )

)

Also, you can check this solved topic : Solved: Re: Override RLS - Microsoft Fabric Community

[v-hashadapu]

Hi @lherbert501 , Thank you for reaching out to the Microsoft Community Forum.

We find the answers shared by @Ritaf1983  & @Zanqueta are correct. Can you please confirm if the solution worked for you. It will help others with similar issues find the answer easily.

Thank you @Ritaf1983 & @Zanqueta  for your valuable responses.

[lherbert501]

Hi @v-hashadapu 

Yes thankyou @Ritaf1983 and @Zanqueta both for your responses.

Both very helpful

Thanks

[Ritaf1983 · Accepted solution]

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

[Zanqueta · Accepted solution]

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.

My suggestion is to create a small security table containing users who should bypass RLS (for example, executives).

The RLS logic then checks whether the current user exists in this table. If so, all rows are visible; otherwise, the hierarchy-based rule applies

VAR IsSuperUser =

    USERPRINCIPALNAME()

        IN VALUES ( RLS_Override[Email] )

RETURN

IF (

    IsSuperUser,

    TRUE(),

    PATHCONTAINS ( 'Employee'[Path], USERPRINCIPALNAME() )

)

Also, you can check this solved topic : Solved: Re: Override RLS - Microsoft Fabric Community