How to Implement RLS in Power BI
Sharing a powerful dashboard with your team is a great feeling, but what happens when you need to make sure each person only sees the data relevant to them? That's where Row-Level Security, or RLS, comes in. This guide will walk you through exactly how to set up RLS in Power BI to control data access, showing you how to build one report that securely serves different audiences.
What is Row-Level Security (RLS) and Why Should You Care?
Row-Level Security is a Power BI feature that restricts data access at the row level based on the user who is viewing the report. In plain English, it means you can create rules that filter your data automatically depending on who’s logged in. A sales manager in California will only see California sales data, while a manager in New York only sees New York data - all from the exact same report.
So, why is this a big deal?
- Data Security and Privacy: The most obvious benefit. RLS ensures that sensitive information is only seen by the right people, reducing the risk of data leaks and reinforcing compliance.
- Simplified Report Management: Instead of building, updating, and maintaining dozens of separate reports for different people or teams (e.g., "NA Sales Report," "EMEA Sales Report"), you can manage a single master report. This saves an enormous amount of time and effort.
- Improved User Experience: Viewers aren’t overwhelmed by data that's irrelevant to them. They get a clean, focused view of their specific area of responsibility, which helps them find insights faster.
Think of it as creating personalized data experiences for your users without the headache of creating personalized reports. You build it once, set the rules, and let Power BI handle the rest.
Before You Start: Getting Your Data Model Ready
Before diving into Power BI, a little prep work with your data model will make the process much smoother, especially if you plan to use a dynamic security model (more on that later). The key is to have a clear way to link users to the data rows they are allowed to see.
Most commonly, this involves having a "dimension" or "lookup" table in your model that maps users to specific data points. For example, you might have a table called 'User Permissions' or 'Sales Reps' that contains at least two columns:
- A column with the user's login ID, typically their email address (e.g., sophia@yourcompany.com). A user's email login is how Power BI recognizes them when they access the report.
- A column linking them to a filterable part of your data (e.g., Territory, Region, Country, or Sales Rep ID).
Let's imagine you have a simple data model with a 'Sales Data' table and a new 'Region Assignments' table. Your 'Region Assignments' table might look like this:
You would then ensure this table is related to your main 'Sales Data' table via the 'Region' column. By setting this up, you give Power BI a roadmap to follow: when Alex logs in, it can see he's assigned to "North America" and will know to only show him sales data from that region.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
Step-by-Step Guide: Implementing RLS in Power BI Desktop
With our data model ready, let's build the security roles inside Power BI Desktop. This is where you'll define the specific filtering rules that bring RLS to life.
1. Open Your Report and Go to "Manage Roles"
First, open your Power PBIX file in Power BI Desktop. Navigate to the Modeling tab on the Ribbon at the top of the window. Here, you'll see a section for Security. Click on Manage roles.
2. Create a New Role
The "Manage roles" window will pop up. This is where you create and define all your security roles. A 'role' is just a named set of filter rules.
Click the Create button. Give your new role a descriptive name. For this example, let's call it Regional Manager.
3. Define the Filtering Rules with DAX
Now for the most important step. With your new 'Regional Manager' role selected, you need to tell Power BI which table to filter and how to filter it.
Let’s use the 'Region Assignments' table from our prep step. In the "Tables" list, find this table and click the ellipsis (...). This will open up a space for a DAX (Data Analysis Expressions) formula.
This is where you'll use a special DAX function: USERPRINCIPALNAME(). This function always returns the login name (usually the email address) of the person currently viewing the report.
In the DAX expression box for the 'Region Assignments' table, type the following formula:
[EmployeeEmail] = USERPRINCIPALNAME()Here's what this expression does:
[EmployeeEmail]: This refers to the 'EmployeeEmail' column in our 'Region Assignments' table.=: This is the equals operator, matching values.USERPRINCIPALNAME(): This grabs the email address of the user who is signed into the Power BI service and viewing the report.
So, when Priya (priya@yourcompany.com) views the report, Power BI effectively filters the 'Region Assignments' table to only show the row where EmployeeEmail is "priya@yourcompany.com". Because that table is related to your main 'Sales Data' table, the sales data gets filtered too, showing only "Europe" data for Priya. This one simple line of DAX is the heart of dynamic RLS.
Click Save when you're done.
4. Validate Your Roles Before Publishing
Never publish without testing! Power BI has a built-in tool that lets you pretend to be a specific user so you can see the report exactly as they would.
On the Modeling tab, click View as. In the "View as roles" window, check the box next to the 'Regional Manager' role you just created. Now, check the box for "Other user" and enter the email address of a user you want to test, for example, alex@yourcompany.com.
Click OK. Your entire report will now be filtered as if you were Alex. You should see a yellow bar at the top of your report confirming "Now viewing report as Regional Manager and alex@yourcompany.com". All the charts and tables should update to show only "North America" data. Test with a few different users to be confident it's working as expected.
Bringing it Live: Managing RLS in the Power BI Service
Creating the roles in Desktop is just the first half. To make them active for your users, you need to publish the report and assign people to the roles in the Power BI Service (the web-based version).
1. Publish Your Report
From Power BI Desktop, go to the Home tab and click Publish. Choose the workspace where you want to share the report and follow the prompts.
After it's published, you'll need to head over to Power BI in your web browser at app.powerbi.com.
2. Navigate to Dataset Security Settings
In your Power BI workspace, find the dataset associated with your report (it will have the same name). Don't go to the report itself. Datasets and reports are listed separately. Hover over the dataset and click the ellipsis (...) that appears, then select Security.
3. Assign Users to Your Role
This will take you to the "Row-Level Security" page. You'll see the 'Regional Manager' role that you created in Desktop. Select the role, and a field will appear allowing you to add users or security groups from your organization.
Start typing the email addresses of the people who should be part of this role (e.g., Alex, Priya, and Chen). Click Add after entering each one, and then be sure to hit Save at the very top of the section.
And that’s it! The next time Alex signs in and opens that report, he will only see North America data because:
- You assigned him to the 'Regional Manager' role in the service.
- That role contains a DAX filter in Desktop that matches his email to the rights in the permissions table.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
Dynamic vs. Static RLS: Which one should you use?
What we just built is known as Dynamic RLS. It uses one role and one DAX formula leveraging USERPRINCIPALNAME() to filter data automatically based on a user permission table. It's scalable, elegant, and easy to maintain. When a new sales associate joins, you just add them to the underlying datasource's permission table (like a spreadsheet or database), and RLS takes care of the rest.
The alternative is Static RLS. With this method, you create a separate role for each different view. For example, you'd create one role named "NorthAmerica," another named "Europe," and so on. The DAX filter for the "NorthAmerica" role would literally be [Region] = "North America". Then, in the Power BI Service, you would manually assign Alex to the "NorthAmerica" role and Priya to the "Europe" role. This works fine for a handful of static groups but quickly becomes a nightmare to manage if you have dozens of regions or hundreds of users.
For almost every situation, dynamic RLS is the better way to go.
Final Thoughts
Implementing Row-Level Security in Power BI is a powerful way to distribute insights across your organization while keeping your data secure and relevant for each user. By setting up roles in Desktop and assigning users in the Power BI service, you can create a single, scalable report that feels tailor-made for every member of your team.
Of course, building reports in tools like Power BI still requires a significant learning curve with DAX formulas, data modeling, and interface quirks. It’s for this exact reason we created a simpler, more intuitive way to work with your data. With Graphed, we connect your data sources in a few clicks, and then you can create real-time dashboards and reports just by asking questions in plain English - no tricky formulas or configurations required. This gives a fast, automated path to the insights you need without the technical overhead.
Related Articles
How to Create Facebook Ads API for Claude Code
Create a Meta Marketing API access token that never expires, using a system user, so Claude Code can pull Facebook ad reports and manage campaigns.
ClickHouse vs Postgres: When to Switch to Columnar
Comparing ClickHouse vs PostgreSQL means matching storage architecture to workload. Row storage wins for transactions. Columnar wins for scan-heavy analytics.
Google Ads for Orthodontists: Get More Booked Consults
Most orthodontic Google Ads campaigns waste money on low-intent searches. The problem is structure, not the platform.