Tag: Row Level Security

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

Configure Row-Level Security Group Membership (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
      --> Configure Row-Level Security Group Membership

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

Configuring Row-Level Security (RLS) group membership is a key governance and scalability topic within the “Manage and secure Power BI (15–20%)” domain of the PL-300: Microsoft Power BI Data Analyst certification exam. This topic builds on basic RLS concepts and focuses on how users are assigned to RLS roles, with an emphasis on using Microsoft Entra ID (Azure AD) security groups instead of individual users.

For the exam, you should understand where RLS roles are defined, where group membership is configured, how group-based RLS behaves, and why it is considered a best practice.

What Is RLS Group Membership?

RLS group membership refers to assigning security groups (rather than individual users) to Row-Level Security roles in a Power BI semantic model. Any user who is a member of the group automatically inherits the data access defined by the role.

This approach:

  • Improves scalability
  • Simplifies administration
  • Aligns with enterprise security standards
  • Reduces ongoing maintenance

Exam Focus: The PL-300 exam strongly favors group-based RLS as the recommended approach.

Where RLS Group Membership Is Configured

Understanding where actions occur is frequently tested.

Power BI Desktop

  • Create RLS roles
  • Define DAX filter expressions
  • No users or groups are assigned here

Power BI Service

  • Assign users or security groups to RLS roles
  • Manage role membership after publishing

Key Distinction:

  • Roles and filters → Desktop
  • Users and groups → Service

Why Use Security Groups for RLS?

Benefits of Group-Based RLS

  • Centralized identity management
    Groups are managed in Microsoft Entra ID, not Power BI.
  • Automatic access updates
    Adding or removing users from a group instantly updates data access.
  • Reduced administrative effort
    No need to modify RLS settings when staff changes.
  • Auditability and compliance
    Easier to review who has access and why.

Exam Tip: If a question asks for the most scalable or best practice approach, choose security groups.

Types of Groups Used in RLS

Supported Group Types

  • Microsoft Entra ID security groups (recommended)
  • Mail-enabled security groups

Not Recommended / Not Supported

  • Distribution lists (not ideal for security)
  • Microsoft 365 groups (not designed for RLS scenarios)

PL-300 Expectation: Know that security groups are the preferred option for RLS role membership.

Assigning Groups to RLS Roles

Step-by-Step (Power BI Service)

  1. Publish the semantic model from Power BI Desktop
  2. In the Power BI Service, open the semantic model
  3. Select Security
  4. Choose an RLS role
  5. Add one or more security groups
  6. Save changes

Once assigned, all group members inherit the role’s data filters.

Group Membership and Dynamic RLS

Group membership is often combined with dynamic RLS for maximum flexibility.

Common Pattern

  • RLS role contains a dynamic filter using USERPRINCIPALNAME()
  • A mapping table links users to business entities (e.g., region, department)
  • A security group controls who is subject to that role

This pattern:

  • Minimizes the number of roles
  • Supports large organizations
  • Separates identity management from data logic

How Group-Based RLS Is Evaluated

When a user opens a report:

  1. Power BI identifies the user’s Entra ID group memberships
  2. The user is matched to assigned RLS roles
  3. The union of all applicable role filters is applied
  4. Only authorized rows are returned

Important Exam Concept:
Users in multiple roles see the combined (union) of allowed data—not the most restrictive set.

Testing Group-Based RLS

In Power BI Desktop

  • Use View as
  • Test role logic only (group membership is not evaluated here)

In Power BI Service

  • Use View as role
  • Or test by signing in as a user who belongs to the group

Exam Awareness: Group membership itself cannot be fully tested in Desktop—only in the Service.

Common Pitfalls (Exam-Relevant)

  • Assigning individual users instead of groups
  • Expecting RLS to apply before publishing
  • Forgetting that group membership changes happen outside Power BI
  • Confusing workspace roles with RLS roles
  • Assuming admins bypass RLS automatically

RLS Group Membership vs Workspace Roles

FeatureWorkspace RolesRLS Group Membership
Controls content access✅❌
Controls data visibility❌✅
Uses Entra ID groups✅✅
Defined in Desktop❌❌
Assigned in Service✅✅

PL-300 Focus: These are complementary—not interchangeable—security mechanisms.

Governance and Best Practices

  • Always prefer security groups over individuals
  • Use clear, business-aligned group names
  • Keep RLS logic simple and documented
  • Coordinate with identity administrators
  • Review group membership regularly

Common Exam Scenarios

You may be asked to identify:

  • The best way to manage RLS for hundreds of users
  • Why a user gained or lost data access without a model change
  • Where to update access when an employee changes roles
  • How group membership impacts RLS evaluation

Key Takeaways for the PL-300 Exam

  • RLS roles are defined in Power BI Desktop
  • Group membership is configured in the Power BI Service
  • Microsoft Entra ID security groups are the recommended approach
  • Group-based RLS improves scalability and governance
  • Users see the union of all assigned RLS roles
  • RLS applies to all reports and apps using the semantic model

Practice Questions

Go to the Practice Questions for this topic.

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.