Row-Level Security in Power BI: The Complete Guide

What RLS Actually Does — and What It Doesn’t

Row-level security filters rows, not visuals, pages, or files. A user with RLS applied still sees the same report, the same pages, and the same visuals as everyone else — they just see fewer rows of data underneath them. That distinction matters because it’s the source of most RLS confusion: people expect RLS to hide entire report pages, and it doesn’t. If you need to hide a page for certain users, that’s a separate technique (dynamic page visibility, or splitting the report into separate apps), not RLS.

RLS is defined once, in Manage Roles, as a DAX filter expression attached to a table. When a restricted user opens the report, Power BI silently adds that filter to every query the model runs on their behalf. They never see the filter, never see a warning, and never see the rows that got excluded — which is exactly the point, but also why untested RLS is dangerous in both directions: it can either expose data that should have been hidden, or hide data a legitimate user actually needed.

Static vs Dynamic RLS — With Real DAX

Both approaches use the exact same mechanism — a DAX filter expression on a table in Manage Roles. The difference is whether the value is hardcoded or looked up per user.

Static RLS

A static role hardcodes one value. It’s simple, but it requires a separate role for every value you want to filter on, and you have to manually assign users to the correct role.

[Region] = "East"

This works fine for a handful of fixed roles — for example, three regional manager roles that rarely change. It falls apart fast once you have dozens or hundreds of distinct filter values, because every new value means a new role and a manual re-publish.

Dynamic RLS

A dynamic role uses USERPRINCIPALNAME() (the user’s email/UPN) or USERNAME() combined with a security mapping table, so one single role filters differently for every user automatically. This is the pattern almost every production deployment actually uses.

[Region] = LOOKUPVALUE(
    SecurityMapping[Region],
    SecurityMapping[UserEmail], USERPRINCIPALNAME()
)

With this pattern, you maintain one small mapping table — ideally synced from Azure AD, an HR system, or a source of truth outside the report — and every user who opens the report gets automatically filtered to their row(s) in that table. Adding a new user’s access is a data change, not a model change.

Building and Testing RLS Step by Step

The Permission Bypass Nobody Warns You About

This is the detail most RLS tutorials skip entirely, and it’s the one that causes real incidents: data-access rules, including RLS, are not enforced for any user who has Write permission on the semantic model. This isn’t a bug — it’s documented, intentional behavior — but it’s easy to miss until it causes a problem.

The fix is structural, not a DAX fix: separate authoring workspaces from distribution. Build and maintain the model in a workspace where only report developers have Contributor-or-higher access, then distribute to end users through a Power BI App, a separate audience-specific workspace where they only hold Viewer access, or row-level-secured embedded scenarios — never by adding restricted business users directly into the authoring workspace.

RLS in Microsoft Fabric — Direct Lake and OneLake Security

Everything above applies to Import and DirectQuery models the same way it always has. Direct Lake changes the mechanics, and Fabric adds an entirely separate security layer — OneLake security — that most Power BI-only content doesn’t cover at all.

RLS on Direct Lake

RLS roles on a Direct Lake semantic model are defined the same way, with the same DAX filter expressions, in the same Manage Roles interface. What changes is evaluation:

• Direct Lake on OneLake (the recommended configuration): the RLS filter is evaluated natively against the Parquet files in OneLake. Simple filters get pushed down efficiently.
• Complex DAX filters fall back automatically: if your RLS expression uses functions Direct Lake can’t evaluate natively — LOOKUPVALUE, PATHCONTAINS, and iterator functions are the common culprits — the engine silently falls back to DirectQuery against the SQL analytics endpoint for that query, which changes performance but not correctness.
• Direct Lake on the SQL analytics endpoint (instead of OneLake): applying RLS here forces a full fallback to DirectQuery for the model. If you’re configuring RLS on a Fabric semantic model, use Direct Lake on OneLake specifically, or you lose the performance benefit Direct Lake exists for.

OneLake Security — A Separate, Earlier Layer

OneLake security lets you define row-level, column-level, and object-level security once, at the OneLake data layer, so the rules apply consistently across every engine that reads the data — Power BI, SQL, Spark, and APIs — rather than redefining security separately in each consuming semantic model. It only applies to Direct Lake semantic models; Import models that copy data into memory aren’t covered by it at all.

Deny-by-default: users have zero access until explicitly granted a role
Most permissive role wins: if a user is in a broad-access role AND
  a restrictive RLS role on the same table, the broad role wins and
  the RLS restriction is silently NOT enforced
Shortcuts: security defined on the source folder applies even when
  accessed through a shortcut in a different Lakehouse

RLS vs OLS vs CLS vs OneLake Security — Who Controls What

Common Mistakes and How to Catch Them

FAQs – Power BI Row-Level Security

Official Resources and Related Guides

Official Microsoft Resources

Related UIG Data Lab Guides