Power BI Row Level Security (RLS): Static, Multiple Values and Dynamic by Email

Your East manager should see East orders only, and Megan Bowen should see her own deals, not everyone’s. Copying the report for each person falls apart by the next refresh.

In this tutorial, we’ll set up power bi row level security on a real 2026 sales model: a static role for one region, a role for multiple values, and a dynamic role based on each user’s email. Then we’ll cover publishing, assigning members and the reasons RLS shows nothing.

Quick answer: Open Modeling > Manage roles, select New, pick a table and add a rule such as [Region] == “East”, or [Email] = USERPRINCIPALNAME() for per-user security. Select Save, test it with Modeling > View as, then publish and add people to the role on the semantic model’s Security page in the Power BI service.

What You Need Before You Start

• Power BI Desktop with an Import or DirectQuery model. Live connections to Analysis Services keep their security in that model instead.
• A Power BI service workspace where you’re a Contributor or higher, so you can assign people to roles.
• For dynamic RLS, a table of users whose email matches each person’s sign-in name.

My demo files are three CSVs loaded with Get data > Text/CSV: Sales (60 orders, $165,701), Targets (one target per region) and Sales Reps. If you’re new to loading files, start with our guide to creating a report in Power BI Desktop.

Here’s the Sales Reps table we’ll secure against:

SalesRep	Email	Title	2026 sales
Adele Vance	adele.vance@spguides.com	Sales Manager	$16,454
Alex Wilber	alex.wilber@spguides.com	Sales Rep	$9,700
Lee Gu	lee.gu@spguides.com	Sales Rep	$48,630
Megan Bowen	megan.bowen@spguides.com	Sales Rep	$46,099
Nestor Wilke	nestor.wilke@spguides.com	Sales Rep	$44,818

Power BI loaded Sales Reps with Column1 to Column3 because every column is text, so we fixed it in Power Query with Use First Row as Headers. It then created the relationships on its own:

Notice the arrow: Sales Reps filters Sales on SalesRep, one to many. That direction is what makes the dynamic role in Step 5 work. Our post on Power BI cross filter direction explains single vs both.

Step 1: Open Manage Roles

The report page has one table, Sales by Rep 2026. Before any role, it shows all five reps and $165,701. Select the Modeling tab, then Manage roles in the Security group.

The Manage security roles dialog opens with three columns: Roles, Tables and Rules.

Step 2: Create a Static Role for One Region

Under Roles, select + New and name the role East Region (role names can’t contain a comma). Select the Sales table, then build the rule: Column Region, Condition Equals, Value East. Select Save.

Power BI confirms with a green bar: “Successfully applied role changes.” Select Switch to DAX editor to see the same rule as DAX:

[Region] == "East"

Every role rule is a DAX filter that returns TRUE or FALSE for each row. Rows that return FALSE disappear for anyone in the role.

Step 3: Test the Role With View As

Select Modeling > View as. In the View as roles dialog, check East Region and select OK.

A banner reads “Now viewing as: East Region” with a Stop viewing button on the right:

The total drops to $81,686, exactly East’s share of sales. Every rep still appears because each one sold in East. The same file drives our walkthrough of percentage of total by category.

Step 4: Filter Multiple Values With IN

Need one role that covers two regions? Create a role named East and West, select Sales, switch to the DAX editor and type:

[Region] IN {"East", "West"}

Select the check mark above the box to apply it. The X next to it reverts your changes.

Switch back to the default editor and the same rule shows as Region | In | East, West. You can add values there with Add +, too.

View as East and West, and the table total is $145,469 (East plus West).

Combine Multiple Conditions

For multiple conditions in one rule, use && for AND and || for OR. The first line below keeps East laptops only; the second keeps every East row plus laptops anywhere. For counting with several conditions, see counting data with multiple filter conditions.

[Region] == "East" && [Category] == "Laptops"

[Region] == "East" || [Category] == "Laptops"

Step 5: Create Dynamic RLS Based on Email

Static roles mean one role per region. Dynamic RLS uses one role for everyone. Create a role named Sales Rep Own Data, select the Sales Reps table and enter this in the DAX editor (the default editor can’t build dynamic rules):

[Email] = USERPRINCIPALNAME()

USERPRINCIPALNAME() returns the signed-in user’s UPN, such as megan.bowen@spguides.com. The rule keeps one Sales Reps row, and the relationship passes that filter to Sales. USERNAME() returns DOMAIN\User in Desktop, so email rules use the UPN; our USERNAME vs USERPRINCIPALNAME guide compares them.

To test it, open View as, check Other user, type megan.bowen@spguides.com, check Sales Rep Own Data and select OK.

Only Megan Bowen is left, with $46,099. The banner names both the role and the email we tested.

Step 6: Publish and Assign Members in the Power BI Service

Roles travel with the model when you publish, but you can’t assign people in Desktop. We follow Microsoft’s steps:

1. Select Publish in Power BI Desktop and pick the workspace.
2. In the workspace, hover over the semantic model, select More options (…), then Security.
3. On the Row-Level Security page, select a role and type a user’s email or a group: distribution, mail-enabled or Microsoft Entra security groups work. Microsoft 365 groups don’t.
4. Select More options next to the role, then Test as role. Choose Back to Row-Level Security when done.

Keep viewers in the workspace Viewer role. RLS doesn’t apply to Admins, Members or Contributors because they can edit the model.

Power BI RLS Cheat Sheet

Goal	Rule (table)	Our result
One value (static)	[Region] == “East” (Sales)	$81,686
Multiple values	[Region] IN {“East”, “West”} (Sales)	$145,469
Each user sees own data	[Email] = USERPRINCIPALNAME() (Sales Reps)	Megan: $46,099
Email not in the table	Same dynamic rule	Empty table
No role	–	$165,701

Common Mistakes: Why Power BI RLS Is Not Working

We reproduced the most common one: View as Other user with diego.siciliani@spguides.com, who isn’t in Sales Reps. The table shows headers and no rows.

• The email doesn’t match the UPN. USERPRINCIPALNAME() returns the sign-in name, which can differ from a mail alias. Store the UPN in your users table.
• The user can edit the workspace. Admins, Members and Contributors see everything. Test with a Viewer.
• Nobody is assigned to the role. Roles do nothing until you add members on the Security page.
• The filter can’t reach the table. RLS filters flow one direction by default. If you need the other way, the relationship has an Apply security filter in both directions option.
• Testing dynamic RLS with Test as role. It uses your own identity, so pick a specific person under Now viewing as instead.

Can a User Belong to Multiple Roles?

Yes, and roles are additive. A user in East Region and Sales Rep Own Data sees rows that either role allows, not only the overlap. For dynamic RLS with multiple roles, keep one dynamic role and let the users table decide who sees what, rather than stacking static roles.

RLS vs OLS in Power BI

RLS hides rows. A user who can see a row sees every column in it. Object-level security hides whole tables or columns, such as the Email column, and visuals that use a hidden field break for that user. Our object-level security guide walks through it in TMDL view.

Next Steps

Once the roles work, add a card with USERPRINCIPALNAME() during testing so each user can see who Power BI thinks they are. For more report-building tutorials, browse our Power BI tutorials.

We’d keep going with these, built on the same sales model:

• How to Calculate Percentage of Two Columns in Power BI
• How to Calculate Percentage of Rows in Power BI
• Power BI DAX Functions with Examples
• Power BI DAX FILTER: A Practical Guide With Examples

Frequently Asked Questions