Why is RLS using FALSE() still showing blank instead of error shows up in Power BI and Excel?

[SylviaFeng]

We're implementing RLS on a semantic model sourced from a Fabric Lakehouse. For one fact table, we assigned a security filter as FALSE() to fully restrict access to that table for a specific group.

Here’s what we observe:

• In Excel and Power BI, when a user with no access opens the report, they see blank visuals instead of an error (e.g., "you do not have access to this data").

• We expected either an error message or some clear indicator of denied access.

• RLS is confirmed working because when switching to an allowed user, the correct data appears.

• The semantic model is deployed in Power BI Service, and we are using USERPRINCIPALNAME() or USERNAME() for security testing.

Question: Is this the expected behavior when using FALSE()?
                Is there any way to surface a visible error/warning to users when RLS blocks their access?

Any insights or suggestions for the feedback are greatly appreciated.

Thank you!

[v-sgandrathi]

Hi @SylviaFeng,

Thank you @tayloramy for your response.

Has your issue been resolved?
If the response provided by the community member addressed your query, could you please confirm? It helps us ensure that the solutions provided are effective and beneficial for everyone.

Thank you for your understanding!

[v-sgandrathi]

Hi @SylviaFeng,

Just wanted to follow up and confirm that everything has been going well on this. Please let me know if there’s anything from our end.
Please feel free to reach out Microsoft fabric community forum.

[v-sgandrathi]

Hi @SylviaFeng,

Just wanted to follow up and confirm that everything has been going well on this. Please let me know if there’s anything from our end.
Please feel free to reach out Microsoft fabric community forum.

[tayloramy · Accepted solution]

Hi @SylviaFeng, 

You are seeing the expected behavior.

RLS filters rows; it does not throw access errors. When a role’s filter evaluates to FALSE() on a table, that table simply returns zero rows for that user, so visuals render blank in both Power BI and Excel. That is by design: RLS is a row filter, not an object permission system, and DAX cannot detect that RLS is in effect. See Microsoft’s guidance: RLS “filters table rows; [it] can’t be configured to restrict access to model objects,” and a rule that evaluates to FALSE returns no rows. DAX also “can’t even determine that RLS is enforced.” (docs) RLS is also honored in Analyze in Excel and the Excel Power BI add-in, so blanks there are expected too (docs; see Considerations and limitations where it confirms RLS/OLS are supported).

If you want a visible message instead of silent blanks, you have a few options:

1. Show a friendly “no access” banner
   Create a tiny Security table that RLS filters to the current user, then drive visuals and a message off of it.
   • Table: Security with one row per allowed user (or mapping to your group logic), column UserUPN.
   • Role filter: Security[UserUPN] = USERPRINCIPALNAME() (or USERNAME() as appropriate; both are supported by Power BI RLS docs).
   • Measures:

     IsAuthorized = IF ( COUNTROWS ( Security ) > 0, 1, 0 )
     
     AccessMessage =
     IF ( [IsAuthorized] = 0,
     "You do not have access to this data. Please contact the owner if you believe this is an error.",
     BLANK()
     )

   • Add visual-level (or page-level) filter [IsAuthorized] is 1 to every analytic visual.
   • Add a Card visual bound to [AccessMessage] that appears only when [IsAuthorized] = 0.
   Note: This distinguishes “no access” from “legitimately no data” if your Security table reliably indicates entitlement. Also, Microsoft recommends placing RLS on a dimension/entitlement table rather than the fact table for performance and propagation reasons (docs).
2. Use Object-Level Security (OLS) for a hard deny
   If your requirement is an explicit permission block instead of blanks, secure the table or sensitive columns with OLS. For users without permission, secured objects “simply do not exist,” and visuals that reference them will be blocked, surfacing a visible error instead of empty results. OLS is defined in model roles (commonly via Tabular Editor) and is supported in Pro and Premium capacities. See: docs and the GA announcement blog.
3. Excel specifically
   Excel honors RLS the same way, so pivots will show blanks if all rows are filtered out. You can surface the same message by adding the [AccessMessage] measure to a PivotTable or by using a CUBEVALUE cell bound to that measure, and directing users accordingly. Microsoft confirms RLS support for Analyze in Excel in the considerations section of the Excel article (docs).

If you found this helpful, consider giving some Kudos. If I answered your question or solved your problem, mark this post as the solution.