Row-Level Security (RLS) — Create basic RLS roles and test them in Desktop (intro)

Enterprise reporting platforms have always grappled with the challenge of serving multiple audiences from a single dataset. In traditional database systems, administrators controlled visibility through views, stored procedures, and per-user schemas — an approach that scaled poorly when hundreds of business users needed personalized slices of the same warehouse. As self-service BI tools gained traction in the 2010s, a new problem surfaced: analysts could build reports from shared models, yet there was no native mechanism to ensure a regional manager in Europe could not inadvertently browse revenue figures belonging to the Asia-Pacific division. Row-Level Security (RLS) emerged as the industry-standard answer, embedding access-control logic directly into the semantic model so that the BI engine itself filters rows before they ever reach a visual.

The central question RLS answers is deceptively simple: How can a single Power BI report serve many users while guaranteeing that each user sees only the rows permitted by their organizational role? Rather than duplicating reports or datasets per department, RLS lets you author once, define roles, attach DAX filter expressions, and let the engine handle the rest — a pattern that computer scientists will recognize as a policy-enforcement layer inserted between the query optimizer and the rendering pipeline.

Before diving into implementation, it is essential to understand the conceptual building blocks that underpin RLS in Power BI. Every RLS configuration revolves around three entities: roles, DAX filter expressions, and member assignments. A role is a named container that groups one or more filter expressions; each expression targets a specific table and restricts which rows are visible when a user belonging to that role queries the model. Member assignments happen in the Power BI Service (or via the XMLA endpoint), where administrators map Azure Active Directory identities to the roles defined in Desktop.

As the diagram illustrates, RLS operates transparently at the engine level. Neither user writes a custom query nor even knows what data has been withheld — the visuals simply render the filtered result set as though it were the entire dataset. This is an important security property: the exclusion is enforced server-side (or engine-side in Desktop during testing), meaning a technically skilled user cannot bypass the filter by, say, exporting the underlying data. The DAX filter expression is the lynchpin of this architecture; it is a Boolean predicate evaluated against every row of the target table, and only rows for which the expression returns TRUE survive into the query result.

Power BI's tabular engine (a descendant of SQL Server Analysis Services VertiPaq) evaluates RLS by wrapping every user-initiated query in an implicit CALCULATETABLE call that appends the role's filter expression to the existing filter context. Understanding this mechanism is crucial because it explains how RLS interacts with relationships, bidirectional cross-filtering, and measures that use ALL() or REMOVEFILTERS(). In formal terms, if a role defines a filter expression F on table T, then every DAX query Q issued by a member of that role is semantically rewritten as follows.

Because the filter is injected into the filter context rather than the row context, it propagates along relationships exactly as any slicer or visual-level filter would. In a standard star schema, placing the RLS expression on a dimension table (e.g., DimRegion) causes the fact table (e.g., FactSales) to be filtered automatically via the active many-to-one relationship. However, if the relationship is set to single-direction cross-filter (the default), placing the filter on the fact table will not propagate back to the dimension table — a subtlety that frequently trips up first-time implementers.

Implementing RLS in Power BI Desktop follows a well-defined workflow: you create one or more roles in the Modeling tab, attach DAX filter expressions to tables within each role, and then use the View as feature to test each role's behavior before publishing. The following diagram captures the end-to-end authoring and testing process.

1. Step 1 — Build the data model. Import your tables and establish relationships. A star schema (dimension tables surrounding a central fact table) is ideal because RLS filters placed on dimensions naturally propagate to the fact table.
2. Step 2 — Create roles. Navigate to Modeling → Manage Roles. Click "Create" and name the role descriptively (e.g., "Europe Sales", "APAC Sales", "Manager").
3. Step 3 — Add DAX filter expressions. Select the table to filter, then enter a DAX expression that evaluates to TRUE or FALSE for each row. For example: [Region] = "Europe" on DimRegion.
4. Step 4 — Test with "View as Roles." Go to Modeling → View as Roles. Check one or more roles and click OK. A yellow banner appears confirming you are viewing the report through the selected role's filter. Verify visuals show only the expected data.
5. Step 5 — Publish and assign members. After publishing, open the dataset's security settings in the Power BI Service. Add Azure AD users or security groups to each role. RLS enforcement begins immediately upon assignment.

Consider a sales analytics model with three tables: FactSales (columns: SalesID, RegionKey, Amount), DimRegion (columns: RegionKey, Region), and DimProduct (columns: ProductKey, ProductName). FactSales has a many-to-one relationship to DimRegion on RegionKey. Our goal is to create two static RLS roles — "Europe Sales" and "APAC Sales" — and verify their behavior in Desktop.

The static RLS approach introduced in this lesson is the foundation upon which more sophisticated patterns are built. As your organization's security requirements grow, you will encounter scenarios that demand dynamic resolution, hierarchical filtering, and hybrid strategies. The table below contrasts the introductory approach with the more advanced patterns you will study next.

Beyond dynamic RLS, Power BI supports Object-Level Security (OLS), which hides entire tables or columns from unauthorized roles rather than filtering rows. OLS is defined through Tabular Editor or the XMLA endpoint and complements RLS when certain metadata itself is sensitive. Additionally, Microsoft Fabric introduces column-level security for Direct Lake models, expanding the governance surface. Mastering static RLS in Desktop, as covered here, gives you the conceptual vocabulary to engage with all of these advanced patterns.