BI Administration, Data Governance, Data Security, Microsoft Certification, PL-300, Power BI

Implement Row-Level Security (RLS) Roles (PL-300 Exam Prep)

 
This post is a part of the PL-300: Microsoft Power BI Data Analyst Exam Prep Hub; and this topic falls under these sections:
Manage and secure Power BI (15–20%)
   --> Secure and govern Power BI items
      --> Implement Row-Level Security (RLS) Roles

Note that there are 10 practice questions (with answers and explanations) at the end of each topic. Also, there are 2 practice tests with 60 questions each available on the hub below all the exam topics.

Overview

Implementing Row-Level Security (RLS) is a critical skill for Power BI Data Analysts and a key topic within the “Manage and secure Power BI (15–20%)” domain of the PL-300: Microsoft Power BI Data Analyst certification exam. RLS ensures that users only see the data they are authorized to view, even when accessing the same reports or semantic models.

For the exam, you must understand how RLS roles are created, how they are implemented using DAX, how users and groups are assigned, and how RLS behaves in the Power BI Service.

What Is Row-Level Security?

Row-Level Security restricts access to specific rows of data in a semantic model based on the identity of the user viewing the report.

RLS:

  • Is defined in Power BI Desktop
  • Uses DAX filter expressions
  • Is enforced in the Power BI Service
  • Applies to all reports that use the semantic model

Key Concept: RLS controls data visibility, not report visibility.

RLS Architecture in Power BI

The RLS workflow consists of four main steps:

  1. Define roles in Power BI Desktop
  2. Create DAX filter expressions for tables
  3. Publish the semantic model to the Power BI Service
  4. Assign users or groups to roles in the Service

Each role defines which rows are visible when the user is a member of that role.

Creating RLS Roles in Power BI Desktop

Step 1: Create Roles

In Power BI Desktop:

  • Go to Model view or Report view
  • Select Modeling → Manage roles
  • Create one or more roles (e.g., SalesWest, SalesEast)

Roles are placeholders until users or groups are assigned in the Power BI Service.

Step 2: Define Table Filters (DAX)

RLS is implemented using DAX filter expressions applied to tables.

Example: Static RLS

[Region] = "West"

This filter ensures that users assigned to the role only see rows where Region equals West.

Exam Tip: RLS filters act like WHERE clauses and reduce visible rows—not columns.

Static vs Dynamic RLS

Static RLS

  • Filters are hardcoded values
  • Each role represents a specific segment
  • Easy to understand, but not scalable

Example:

[Department] = "Finance"

Dynamic RLS (Highly Exam-Relevant)

Dynamic RLS uses the logged-in user’s identity to filter data automatically.

Common functions:

  • USERPRINCIPALNAME()
  • USERNAME()

Example:

[Email] = USERPRINCIPALNAME()

Dynamic RLS:

  • Scales well
  • Reduces number of roles
  • Is commonly used in enterprise models

Best Practice: Use dynamic RLS with a user-to-dimension mapping table.

Assigning Users to RLS Roles (Power BI Service)

After publishing the semantic model:

  1. Go to the Power BI Service
  2. Navigate to the semantic model
  3. Select Security
  4. Assign users or Microsoft Entra ID (Azure AD) groups to roles

Best Practice: Always assign security groups, not individual users.

Testing RLS

In Power BI Desktop

  • Use Modeling → View as
  • Test roles before publishing
  • Validate DAX logic

In Power BI Service

  • Use View as role
  • Confirm correct filtering for assigned users

Exam Tip: “View as” does not bypass RLS—it simulates user access.

RLS Behavior in Common Scenarios

Reports and Dashboards

  • RLS applies automatically
  • Users cannot see restricted data
  • Visual totals reflect filtered data

Power BI Apps

  • RLS is enforced
  • No additional configuration required

Analyze in Excel / External Tools

  • RLS is enforced if the user has Build permission
  • Users cannot bypass RLS through external connections

Important RLS Limitations (Exam Awareness)

  • RLS does not hide tables or columns (use Object-Level Security for that)
  • RLS cannot be applied directly to measures
  • Workspace Admins are not exempt from RLS unless explicitly configured
  • RLS does not apply in Power BI Desktop for the model author unless using “View as”

Object-Level Security (OLS) vs RLS

FeatureRLSOLS
Controls rows✅❌
Controls columns/tables❌✅
Configured in Desktop✅❌ (External tools)
Exam depthHighAwareness only

PL-300 Focus: RLS concepts are tested far more deeply than OLS.

Governance and Best Practices

  • Use dynamic RLS wherever possible
  • Centralize security logic in the semantic model
  • Use groups, not individuals
  • Document role logic for maintainability
  • Test RLS thoroughly before sharing reports

Common Exam Scenarios

You may be asked to determine:

  • Why different users see different values in the same report
  • How to reduce the number of RLS roles
  • How to implement user-based filtering
  • Where RLS logic is created vs enforced

Key Takeaways for the PL-300 Exam

  • RLS restricts row-level data visibility
  • Roles and filters are created in Power BI Desktop
  • Users and groups are assigned in the Power BI Service
  • Dynamic RLS uses USERPRINCIPALNAME()
  • RLS applies to all reports and apps using the semantic model
  • RLS is enforced at the semantic model level

Practice Questions

Go to the Practice Questions for this topic.

Leave a comment