Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!The Power BI Data Visualization World Championships is back! It's time to submit your entry. Live now!
Goal: I need to allow a users to bypass all Row-Level Security (RLS) rules only when they are viewing a specific report. All existing RLS must remain fully enforced for the users when they are using any other report. All reports connect to a single semantic model.
Description of the Current Architecture:
We have one central semantic model (dataset) published to the Power BI Service.
This model has over 20 distinct RLS roles. Users are often members of multiple roles.
Numerous reports are built on this single model, each inheriting its RLS rules.
The Specific Challenge & What I've Tried:
The core problem is that RLS is applied at the dataset level, not the report level. I understand that a user who is a member of any role granting access to a row can see that row. This means simply adding a privileged user to a new bypass role would break their existing departmental restrictions across all reports, which is unacceptable. I have already investigated and ruled out the following:
TREAT AS/ CROSSFILTER in DAX measures: These cannot override filters applied by RLS, as RLS is applied before DAX calculations.
Creating a duplicate table in the model: This works technically but is not a feasible solution as it bloats the model and creates a maintenance nightmare.
Building a separate, unfiltered dataset: This is my last option. I am seeking a solution within the same semantic model for maintainability before pursuing this architectural split
Thank you for taking the time to read this. Any insights or alternative approaches would be appreciated.
Solved! Go to Solution.
Hi @rask
RLS is applied at the semantic model level so it isn't aware but report it is currently being used in. I've tried bypassing it by creating a disconnected table with a column containing values whether it is bypass rls or not and a condition to RLS. This didnt work.
IF (
[Bypass?] = "Yes",
TRUE (),
[Email] = [current user] --replace with USERPRINCIPALNAME()
)
Overwriting the fillter direction using CROSSFILTER didnt work as well.
Your alternative, if you want to maintain "a" semantic model, is to disable RLS and apply the filter directly using measures.
Sales - pseudo-bypassed =
VAR _bypass = SELECTEDVALUE ( Bypass[Bypass], "no" ) -- default to no
VAR _currentUser = [current user]
RETURN
IF (
_bypass = "yes",
[Sales],
CALCULATE ( [Sales], KEEPFILTERS ( Employee[Email] = _currentUser ) )
)
Ensure to hide the filter pane.
Please see the attached pbix.
Hi @rask ,
Thank you for engaging with the Microsoft Fabric Community. In addition to the explanation above, I’ve also attached an official Microsoft article for your reference: Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
This document outlines how RLS works, its current limitations, and why it’s enforced at the semantic model level rather than the report level. It also clarifies why techniques like TREAT AS/ CROSSFILTER, or disconnected tables can’t override the RLS context.
Thankf for your response @danextian .
Hope this helps.
Regards,
Yugandhar
Hi @rask ,
Could you let us know if your issue has been resolved or if you are still experiencing difficulties? Your feedback is valuable to the community and can help others facing similar problems.
Hi @rask ,
I wanted to follow up to see if your issue has been resolved or if you still need any assistance. If you need more information, feel free to let me know.
Thank you.
Hi @rask ,
Could you please confirm whether the issue has been resolved or if further assistance is needed? Your input is valuable and helps us improve support for similar cases.
Hi @rask ,
Thank you for engaging with the Microsoft Fabric Community. In addition to the explanation above, I’ve also attached an official Microsoft article for your reference: Row-level security (RLS) with Power BI - Microsoft Fabric | Microsoft Learn
This document outlines how RLS works, its current limitations, and why it’s enforced at the semantic model level rather than the report level. It also clarifies why techniques like TREAT AS/ CROSSFILTER, or disconnected tables can’t override the RLS context.
Thankf for your response @danextian .
Hope this helps.
Regards,
Yugandhar
Hi @rask
RLS is applied at the semantic model level so it isn't aware but report it is currently being used in. I've tried bypassing it by creating a disconnected table with a column containing values whether it is bypass rls or not and a condition to RLS. This didnt work.
IF (
[Bypass?] = "Yes",
TRUE (),
[Email] = [current user] --replace with USERPRINCIPALNAME()
)
Overwriting the fillter direction using CROSSFILTER didnt work as well.
Your alternative, if you want to maintain "a" semantic model, is to disable RLS and apply the filter directly using measures.
Sales - pseudo-bypassed =
VAR _bypass = SELECTEDVALUE ( Bypass[Bypass], "no" ) -- default to no
VAR _currentUser = [current user]
RETURN
IF (
_bypass = "yes",
[Sales],
CALCULATE ( [Sales], KEEPFILTERS ( Employee[Email] = _currentUser ) )
)
Ensure to hide the filter pane.
Please see the attached pbix.
Can you create a workspace with the specific report which should have all access and publish it with contributor privilege? But share the report via app?
Let me know if this helps
Regards,
Rajashri N
If the report is connected to the same semantic model, the users won't still be able to bypass RLS even if they're given a higher role in the workspace a copy of the report is published in.
I stand corrected, thanks 🙂
| User | Count |
|---|---|
| 53 | |
| 40 | |
| 35 | |
| 24 | |
| 22 |
| User | Count |
|---|---|
| 136 | |
| 111 | |
| 58 | |
| 43 | |
| 38 |