Professional Workflow›Pro· 40 min read

Row-Level Security (RLS): Show Each User Their Own Data

One report, but each manager sees only their own region — RLS filters the data by who is viewing.

What you will learn

Explain what Row-Level Security does and why teams need it
Create a role with a DAX filter rule
Test a role with View as before publishing

One report, different data per person

Imagine a sales report shared with five regional managers. The North manager should see only North; the South manager should see only South. You could build five copies — but that is a nightmare to maintain. Row-Level Security (RLS) solves it: one report that automatically filters the data based on who is signed in.

“Row-level” means the security works at the level of rows: it decides which rows of your tables each person is allowed to see, before any visual is drawn.

The two pieces: roles and rules

RLS has just two parts:

A role — a named group, like “North Manager”. You will assign real people to it later in the Service.
A rule — a DAX condition on a table that says which rows that role may see, e.g. “only rows where Region is North”.

Creating a role — step by step

In Power BI Desktop, on the Modeling ribbon, click Manage roles:

Click Manage roles → Create and name the role, e.g. North Manager.
Pick the table to filter (e.g. Sales or the Region dimension).
Write a DAX filter rule that returns true only for allowed rows.
Click Save. Repeat for each region you need.

A fixed rule for the North role looks like this:

A simple RLS rule: this role only sees North rows

Table:  Sales
Rule:   [Region] = "North"

Note: Output: Anyone assigned to the North Manager role now sees Sales filtered to Region = “North” everywhere — every card, chart and table on every page silently shows only North data. Other regions are not hidden by formatting; the rows are removed before the report even renders, so the totals are correct for that person.

Dynamic RLS — one rule for everyone

Writing one role per region does not scale to fifty regions. Dynamic RLS uses one rule that compares each row to the signed-in user’s email, captured by the DAX function USERPRINCIPALNAME() (it returns the current viewer’s login name). You keep a small table that maps each email to the region they may see.

Dynamic RLS: match each row to whoever is signed in

Table:  Region
Rule:   [RegionManagerEmail] = USERPRINCIPALNAME()

Note: Output: When asha@shop.com opens the report, USERPRINCIPALNAME() returns “asha@shop.com”, so only the regions whose manager email equals that value pass the filter — Asha sees just her regions. Ravi sees only his. One rule now serves every manager, and adding a new manager means adding one row to the mapping table, not a new role.

Always test before you ship

Never publish RLS untested — a mistake could leak data. Power BI lets you preview any role with View as:

On the Modeling ribbon, click View as.
Tick a role (e.g. North Manager) — and for dynamic RLS, also tick Other user and type a test email.
The whole report instantly re-renders as that role would see it.
Confirm only the allowed rows show, then click View as → none to return to normal.

Note: Output: With “North Manager” selected in View as, every visual shows only North — Total Sales drops to North’s figure and the table lists North rows only. This proves the rule works before any real user is affected. Switch it off and you see all data again as the report author.

The last step: assign people in the Service

Roles you create in Desktop are empty — they define the filter but contain no people. After you publish, you open the dataset in the Power BI Service → Security, and add real users or groups to each role. Only then does RLS apply to those people when they view the report.

Tip: Filter the dimension table (e.g. Region) rather than the big fact table when you can. The one-to-many relationship then pushes the filter down into Sales automatically, and the rule stays small and fast.

Watch out: RLS does not apply to people with Admin/Member/Contributor access to the workspace or to the report author — they see everything. RLS restricts Viewers. Always assign the right roles and give end users only Viewer access, or the security will not take effect.

Q. What does Row-Level Security (RLS) do?

Answer: RLS uses roles with DAX rules to restrict the rows each viewer can see — e.g. a North manager sees only North data — from one shared report. Test it with View as before publishing.

✍️ Practice

Create a role that filters Sales to one region, then use View as to confirm it works.
Write a dynamic rule with USERPRINCIPALNAME() against a small email-to-region mapping table.

🏠 Homework

Build two regional roles, test each with View as, and write the exact steps you would take in the Service to assign real users to them.