PL-300: how to implement row-level security (RLS) in Power BI

João Barros 04 de October de 2026 4 min read

I will teach how to implement Row-Level Security (RLS) in Power BI — a competency in the "Manage and secure Power BI resources" domain of the PL-300 exam. RLS is essential to limit the data visible to each user and is frequently assessed both in practical exam scenarios and in enterprise implementations.

What you need to know

Row-Level Security (RLS) allows you to restrict which rows of a table each user (or group) can see in a report or dataset. There are two main modes:

Static RLS: you define roles with static rules (e.g.: [Country] = "Portugal") in the model and then assign users or groups to those roles in the Power BI service.
Dynamic RLS: the rule depends on the user's identity at runtime (for example, comparing [UserEmail] with USERPRINCIPALNAME()). It allows managing permissions without explicitly mapping each user to a role.

Simple example: you have a Sales table with a Region column. You want the user to see only sales from their region. In Static RLS you create a Role RegionFilter with the expression [Region] = "North". In Dynamic RLS, you use a table that maps users to regions and filter with USERPRINCIPALNAME().

How it works (step-by-step)

Follow this practical process to implement RLS in a typical solution:

Prepare the model: ensure you have a key that links the fact table (e.g.: Sales) to the dimension that contains the permission assignments (e.g.: Users or Regions). E.g.: Sales[RegionID] relates to Regions[RegionID].
Create a mapping table (for Dynamic RLS): create a Users table with columns [UserPrincipalName] and [RegionID]. You can keep it inside the model or bring it from a source.

Define the RLS role in Power BI Desktop:

Modeling > Manage roles > Create > Role name: RegionRole -- If Static: Regions[RegionName] = "North"  -- If Dynamic: Regions[RegionID] IN VALUES(Users[RegionID])

The expression in the role manager is a DAX that returns true for the allowed rows.

Test the role in Desktop: use View as Roles (Modeling > View as) to simulate a user or role. For dynamic RLS use the "Other user" option and enter the email to test filtering with USERPRINCIPALNAME().
Publish and assign users in the Power BI service: publish the report to a workspace in the service. In Datasets > Security select the role you created and add users or groups (Azure AD) for Static RLS. For Dynamic RLS you do not add mappings here: the rule uses the user's identity when they access.
Test in the service: use the "Test as role" option if available, or ask a real user with the appropriate credentials to validate the experience in the published report.

In practice: DAX example for Dynamic RLS

A common pattern is to compare the user's email with the mapping table. Example of an expression in a role:

-- Role: RegionalAccess CONTAINS(   Users,   Users[UserPrincipalName],   USERPRINCIPALNAME(),   Users[RegionID],   Regions[RegionID] )

A simpler alternative (when the relationship is defined between Users and Regions):

Users[UserPrincipalName] = USERPRINCIPALNAME()

The latter assumes that, via the relationship, it filters all rows of the Regions dimension and, consequently, the related Sales rows.

Common mistakes

Assuming RLS works without correct relationships: if there is no relationship between the mapping table and the fact table, filtering will not propagate.
Using USERPRINCIPALNAME() in Desktop without proper testing: in Desktop the value may be your user; use "View as" and the "Other user" option to simulate other users.
Adding users to the workspace instead of to the role (confusion): giving access to the workspace does not replace RLS — it may grant access to reports, but the data is still filtered by RLS if configured.

How to practice

Practice creating both static and dynamic RLS in sample models. Use datasets with a users dimension and clear relationships. For exam preparation, take the OFFICIAL and free Microsoft Practice Assessment and consult the official study guide (also free) — these resources help understand what the exam measures without providing real questions.

In summary

RLS restricts row-by-row what each user sees; there is Static and Dynamic RLS.
Dynamic RLS uses DAX functions like USERPRINCIPALNAME() and a mapping table to avoid managing user lists manually.
Correct relationships in the model are essential for RLS to propagate to fact tables.
Always test in Desktop (View as) and in the Power BI service; in the service assign users to roles for Static RLS.