Power BI Row Level Security Setup
Row Level Security (RLS) controls which rows of data each person can see in a Power BI report. Without RLS, every person who can access a report sees all the data. With RLS, a North Region sales manager sees only North Region data, while a South Region manager sees only South Region data — both accessing the same report, but each seeing a personalized filtered view.
Why RLS Matters
Imagine you have a sales performance report showing every salesperson's revenue, targets, and performance ratings. You share this report with your entire sales team of fifty people. Without RLS, every salesperson sees everyone else's data — their colleagues' revenue figures, targets, and performance. This is a privacy and sensitivity problem in most organizations.
With RLS, each salesperson opens the same report but sees only their own data. The report, the dataset, and the visuals are identical — only the data rows shown to each person differ.
RLS is also required for compliance with data privacy regulations. Financial data shared across departments, patient data in healthcare, or salary data in HR all require controlled access at the row level.
How RLS Works — The Basic Concept
RLS works by applying a filter to one or more tables based on the identity of the logged-in user. When a user opens the report, Power BI checks who they are (their login email), matches it against your RLS rules, and shows only the rows that match.
The filter is invisible to the end user. They cannot see or bypass it. They see a fully functional report — they just see a version of it that contains only their authorized data.
Setting Up Static RLS
Static RLS is the simpler approach. You define fixed rules that manually assign each role to see specific data.
Step 1 — Create a Role in Power BI Desktop
Go to the Modeling tab in the ribbon and click Manage Roles. A dialog opens. Click Create to add a new role. Give the role a descriptive name — for example "North Region" or "Sales Manager."
In the Tables section, select the table you want to filter. A DAX filter expression box appears. Enter a DAX expression that returns TRUE for the rows this role should see.
For a North Region role filtering a Sales table that has a Region column:
[Region] = "North"
Click the checkmark to confirm. Create additional roles for South, East, and West regions following the same process. Click Save when done.
Step 2 — Test the Roles in Power BI Desktop
Go to the Modeling tab and click View as. A dialog shows all the roles you created. Select "North Region" and click OK. The entire report now displays as if you are a user in the North Region role — only North data appears. Select "Other User" and enter a colleague's email to simulate their view if their email determines their role.
Testing roles before publishing prevents the embarrassing situation of publishing a report with RLS that does not work correctly.
Step 3 — Publish the Report to Power BI Service
Click Publish in the Home tab to push the report and dataset to Power BI Service. The roles you created in Desktop are included in the published dataset.
Step 4 — Assign People to Roles in Power BI Service
In Power BI Service, go to your workspace. Find the published dataset (not the report). Click the three-dot menu next to the dataset and select Security. The Row Level Security management page opens.
You see the roles you created. Click a role — for example "North Region." A box appears where you enter the email addresses of people who should see only North Region data. Type each email address and click Add. Repeat for each role.
Setting Up Dynamic RLS
Static RLS requires manual updates every time staff changes occur — when someone joins, leaves, or moves regions. Dynamic RLS eliminates this maintenance by automatically determining what each user sees based on their email address stored in your data.
Create a Security Table
Add a table to your data model — either from your database or a manually maintained spreadsheet — that maps each person's email address to their authorized region, department, or data segment.
Example structure:
- Email: anita.sharma@company.com | Region: North
- Email: ravi.kumar@company.com | Region: South
- Email: priya.mehta@company.com | Region: East
Connect this Security table to the rest of your data model through the Region column (linked to your Sales table or Dimension table that has a Region column).
Create a Dynamic Role
In Manage Roles, create one role — for example "Employee Access." In the filter expression for the Security table, use the USERPRINCIPALNAME() function:
[Email] = USERPRINCIPALNAME()
USERPRINCIPALNAME() returns the email address of the currently logged-in user. When Anita opens the report, her email (anita.sharma@company.com) is returned, matches her row in the Security table, and Power BI restricts her view to North region data. When Ravi opens it, his email returns South region data.
Assign All Users to the Dynamic Role
In Power BI Service's Security settings for the dataset, assign every user (or the entire team group) to the single dynamic role you created. The dynamic filter formula handles the per-user data restriction automatically.
RLS Does Not Protect the Data Model Structure
RLS restricts data rows but does not hide column names, measure names, or the data model structure from users who have access to the dataset. If a user has Build permission on a dataset, they can connect to it through Excel or Power BI Desktop and potentially see the model structure even if RLS limits the data rows they retrieve.
For highly sensitive scenarios where even the model structure must be hidden, use separate datasets with separate models for different user groups rather than relying on RLS alone.