ExamFinch.com My Study

Study guide

11.1 Row-Level Security (RLS)

Practice this exam

Microsoft Power BI Data Analyst PL-300

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the PL-300 Exam The Power BI Ecosystem

2 Chapter 1: Get or Connect to Data

1.1 Data Source Types and Connections 1.2 Storage Modes: Import, DirectQuery, and Direct Lake 1.3 Data Source Settings and Parameters

3 Chapter 2: Profile and Clean the Data

2.1 Data Profiling in Power Query 2.2 Resolving Errors, Nulls, and Data Quality Issues 2.3 Data Types and Type Detection

4 Chapter 3: Transform and Load the Data

3.1 Column Transformations and Data Types 3.2 Grouping, Aggregating, Pivoting, and Unpivoting 3.3 Merge Queries, Append Queries, and Relationship Keys 3.4 Query Folding and Load Performance

5 Chapter 4: Design and Implement a Data Model

4.1 Star Schema Design 4.2 Relationships, Cardinality, and Cross-Filter Direction 4.3 Table and Column Properties 4.4 Calculated Columns and Calculated Tables

6 Chapter 5: Create Model Calculations with DAX

5.1 DAX Fundamentals and Measures 5.2 The CALCULATE Function 5.3 Time Intelligence Measures 5.4 Statistical Functions, Semi-Additive Measures, and Calculation Groups 5.5 Essential DAX Patterns and Functions Reference

7 Chapter 6: Optimize Model Performance

6.1 Performance Analyzer and DAX Query View 6.2 Model Size Reduction and Cardinality Management 6.3 DAX Optimization Patterns

8 Chapter 7: Create Reports

7.1 Visual Types and Selection 7.2 Visual Formatting and Conditional Formatting 7.3 Copilot in Power BI Reports 7.4 Report Page Configuration and Slicers

9 Chapter 8: Enhance Reports for Usability and Storytelling

8.1 Bookmarks, Navigation, and Drillthrough 8.2 Sorting, Selection Pane, Mobile Layout, and Accessibility 8.3 Export Settings and Automatic Page Refresh

10 Chapter 9: Identify Patterns and Trends

9.1 The Analyze Feature and AI Visuals 9.2 Using Copilot to Summarize the Semantic Model 9.3 Advanced Analytics Patterns

11 Chapter 10: Create and Manage Workspaces and Assets

10.1 Workspaces, Apps, and Content Distribution 10.2 Subscriptions, Alerts, and Semantic Model Refresh 10.3 Dashboards and Advanced Distribution

12 Chapter 11: Secure and Govern Power BI Items

11.1 Row-Level Security (RLS) 11.2 Sensitivity Labels, Item Access, and Governance 11.3 Deployment Pipelines and Content Lifecycle

11.1 Row-Level Security (RLS)

Key Takeaways Explain This Topic AI

RLS filters rows by role: define roles with DAX filter expressions in Desktop (Manage roles), then assign users or security groups to roles in the service.

Static RLS hard-codes filter values and needs one role per value; dynamic RLS uses USERPRINCIPALNAME() with a mapping table so a single role serves everyone and scales.

Workspace Admins and Members always bypass RLS, so you must test with Modeling -> View as (entering a test UPN for dynamic RLS); only Viewers/Contributors/app consumers are subject to RLS.

A user assigned to multiple roles sees the union of all their roles' filters, and a user in no role sees all data.

Object-Level Security (OLS) hides entire tables or columns from a role and complements RLS, which filters rows.

Last updated: June 2026

Quick Answer: Row-Level Security (RLS) filters which rows a user sees based on their assigned role. Define roles in Desktop (Modeling -> Manage roles) with DAX filter expressions , then assign users/groups to roles in the service . Static RLS hard-codes filter values ( [Region] = "West" ); dynamic RLS uses USERPRINCIPALNAME() plus a mapping table so one role serves everyone. Workspace Admins/Members bypass RLS entirely. RLS is one of the most heavily tested PL-300 topics.

What RLS does

Two users open the same report and see different data: the West manager sees only West rows, the East manager only East rows, the VP sees everything. RLS enforces this through roles — named sets of DAX filters applied to tables.

Creating roles in Desktop

Modeling tab -> Manage roles -> Create -> name the role -> pick a table -> write a DAX filter.

  • Static RLS
  • Hard-coded values, one role per value: // Role "West Region", table Sales
  • [Region] = "West"

Simple, but it does not scale — 50 regions means 50 roles to build and maintain.

Dynamic RLS

One role that filters by the signed-in user's identity. USERPRINCIPALNAME() returns the user's UPN (usually their email, e.g., john@contoso.com ). Pair it with a mapping table:

  • Email Region
  • john@contoso.com West
  • sarah@contoso.com East
  • Two common patterns: // Pattern A - filter the data table directly via LOOKUPVALUE

[Region] = LOOKUPVALUE(UserRegion[Region], UserRegion[Email], USERPRINCIPALNAME()) // Pattern B - filter the security (mapping) table; the relationship propagates the filter

// Role on the UserRegion table:

[Email] = USERPRINCIPALNAME()

Pattern B is preferred at scale: build a relationship from the mapping table to Sales so the filter propagates automatically . Permission changes mean editing one table, not re-publishing roles. USERNAME() returns domain\user (and behaves like UPN in the service), but USERPRINCIPALNAME() is the standard choice for cloud RLS.

Testing RLS

In Desktop: Modeling -> View as -> select role(s) , and for dynamic RLS also enter Other user (a test UPN) so USERPRINCIPALNAME() resolves to that value. Verify users see only allowed rows, totals reflect only visible data, all visuals respect the filter, cross-filtering still works, and measures honor the RLS filter context.

Assigning users in the service

Workspace -> semantic model -> Security -> pick role -> add members (emails or Azure AD/Entra security groups ). Using groups centralizes management and auditing.

Role assignment rules (exam-critical)

A user in no role sees all data (RLS does not apply to them — assign every consumer to a role).

Admins and Members of the workspace always see all data , regardless of RLS — so you cannot test RLS by viewing as yourself; use View as .

Only Viewers/Contributors and app consumers are subject to RLS.

A user in multiple roles sees the union of all their roles' filters (access is additive, not intersected).

RLS with other configurations

DirectQuery: the RLS filter is pushed into every source query; complex filters can affect performance.

Live connection to Analysis Services: RLS lives in the SSAS/AAS model; Power BI passes the user identity through.

Shared semantic model: RLS defined on the dataset is inherited by every report built on it — enforcement is at the model level, not per report.

Object-Level Security (OLS)

OLS hides entire tables or columns from a role (defined via Tabular Editor or the XMLA endpoint). It complements RLS (which filters rows). Example: hide the Salary column from the Manager role while HR keeps it.

Manager hierarchies with PATH (advanced dynamic RLS)

A frequent advanced scenario: a sales VP should see their own data and everyone who rolls up to them . A flat email-to-region map can't express a hierarchy, so you use a parent-child pattern. Add a PATH column to the employee/security table: Hierarchy Path = PATH(Employee[EmployeeID], Employee[ManagerID]) , which stores each employee's chain of ancestors (e.g., 1|7|42 ). Then the dynamic RLS role filters with PATHCONTAINS : // Role on Employee table - a user sees themselves and all reports beneath them

  • PATHCONTAINS(
  • Employee[Hierarchy Path],
  • LOOKUPVALUE(Employee[EmployeeID], Employee[Email], USERPRINCIPALNAME())
  • )

This returns every employee whose path contains the logged-in user's ID — i.e., the user and their entire downline — which is exactly the org-chart filtering pattern the exam describes as "managers see their team's data."

Common RLS mistakes the exam probes

Testing as yourself with Admin/Member access shows all data because Admins/Members bypass RLS — always use View as .

Forgetting to assign users to any role means they see everything , not nothing.

Bidirectional relationships can leak rows across an RLS filter; Power BI may require you to enable "Apply security filter in both directions" deliberately, and over-using bidirectional filters is a common RLS bug.

A user in two roles sees the union , so adding a broad role to someone who also has a narrow role widens their access — never assume roles intersect.

Measures must respect filter context : a measure using ALL() can blow past RLS for totals if written carelessly; verify totals in View as.

On the exam

Expect: choose dynamic RLS + mapping table for 50 managers and PATH/PATHCONTAINS for an org-chart hierarchy; recall USERPRINCIPALNAME() returns the user's email/UPN; know Admins/Members bypass RLS so you must use View as ; understand multiple roles = union of filters and that an unassigned user sees all data ; and distinguish RLS (rows) from OLS (tables/columns) .