Row-level security in Power BI, step by step

Row-level security (RLS) lets one Power BI report show each person only the rows they are allowed to see: a regional manager sees their region, a sales rep sees their accounts, all from the same report. This guide builds RLS two ways, a static role and a dynamic role, then shows how to test it, publish it, assign people, and avoid the mistakes that either leak data or block everyone. It is for the report author who needs to control who sees what without maintaining a separate copy per audience.

Before you start

• A Power BI Desktop file with a working model (a star schema, ideally) and a column you want to filter on, for example Region or SalesRepEmail.
• A Power BI (Fabric) workspace you can publish to.
• For dynamic RLS, a security or mapping table that links each person's login to the data they may see.

1. Understand what RLS does and does not do

RLS filters rows for users who consume the report as Viewers. It does not hide columns, and it does not apply to workspace Admins, Members, or Contributors, who see everything. So RLS protects data from your report audience, not from your report editors. Plan your workspace roles with that in mind.

2. Create a static role with a DAX filter

A static role hard-codes the filter. It is the simplest form and works well when you have a small, fixed number of audiences.

1. In Power BI Desktop, on the Modeling tab select Manage roles.
2. Select New, name the role (for example, North Region).
3. Pick the table to filter (for example, the Region dimension) and enter a DAX filter:

[Region] = "North"

4. Repeat for each region you need as its own role. Select Save.

Static roles are easy to read, but they multiply: one role per region means editing the model every time a region is added. That is where dynamic RLS earns its keep.

3. Build dynamic RLS with USERPRINCIPALNAME

Dynamic RLS uses one role for everyone and filters based on who is signed in, by matching their login against a mapping table.

1. Make sure your model has a security table with at least two columns: the user's login (their User Principal Name, usually their email) and the value they may see (for example, Region). Relate it to your data so the filter can flow.
2. On the Modeling tab, select Manage roles, then New, and name the role (for example, Dynamic Region).
3. On the security table, enter a DAX filter that matches the current user:

[UserEmail] = USERPRINCIPALNAME ()

4. Save. Now one role serves everyone: each person sees only the rows whose mapping links to their login.

4. Test with View as

Do not publish and hope. Test in Desktop first.

1. On the Modeling tab, select View as (View as roles).
2. Check a role to see the report as that role sees it.
3. For dynamic RLS, also check Other user and type a real UPN from your security table, alongside the role, to simulate that specific person.
4. Confirm the data narrows correctly. Select Stop viewing when done.

5. Publish and assign people to roles

The roles travel with the model, but you assign people in the service.

1. Publish the report to your workspace.
2. In the service, find the semantic model, select the More options (...) menu, and choose Security.
3. For each role, add the users or security groups who belong in it, and select Save. Using Microsoft Entra security groups instead of individual people keeps this manageable as staff change.

6. Test as role in the service

1. On the same Security screen, select the ... next to a role and choose Test as role.
2. Confirm the report shows only that role's data.
3. For dynamic RLS, test with a couple of real identities, including an edge case like someone who maps to nothing.

7. Avoid the mistakes that leak or block data

• Leaving Viewers out of a role: if RLS is on but a Viewer is in no role, they see nothing. If you forget to enable RLS at all and rely on it, everyone sees everything. Confirm both the role assignment and that RLS is actually filtering.
• A mismatch between the stored login and the UPN: the most common dynamic-RLS failure. The security table must hold the exact work email the service signs in with.
• Bidirectional relationships: these can cause the security filter to flow in unexpected directions and either leak rows or block them. Keep relationships single-direction unless you have tested the RLS result with them set to both.
• Trusting RLS to hide columns: it does not. If a column is sensitive, RLS is the wrong tool; it filters rows only.

Verify before you hand it over

With real assignments in place, have one person from each audience open the report and confirm they see their data and only their data. Watch especially for someone who can see a region they should not, and for someone who sees a blank report when they should see rows. Both point back to the role assignment or the mapping table.

What to do next

With static and dynamic RLS working, one report can safely serve your whole organization. As you grow, lean on Microsoft Entra security groups for assignments and keep your mapping table as the single source of truth for who sees what. RLS that quietly leaks or blocks data is a common and high-stakes mistake, so if you want a second set of eyes before this report goes wide, that is exactly the kind of review we do for SMBs. Let's make sure it is airtight.