How to Check RLS in Power BI Service
You’ve done the hard work of setting up Row-Level Security (RLS) in your Power BI report to make sure people only see the data they’re supposed to see. But once you publish it to the Power BI Service, how do you know it’s actually working? Hitting publish and just hoping for the best isn’t a strategy. This guide breaks down exactly how to check your RLS implementation in the Power BI Service, so you can share your reports with confidence.
A Quick Refresher: What is Row-Level Security?
Row-Level Security (RLS) is a Power BI feature that restricts data access for specific users. Instead of creating multiple versions of the same report for different audiences (one for the East region sales team, one for the West, etc.), you can create one report and define security "roles." When a user from the East region opens the report, they only see rows of data related to the East region. It’s a powerful way to secure your data and streamline your reporting process.
But building RLS is only half the battle. If it’s misconfigured, you could accidentally show a sales rep the entire company’s performance data or, even worse, show them nothing at all. That’s why testing is not just a nice-to-have, it’s an essential final step before you let your report out into the wild.
Part 1: The First Checkpoint - Testing RLS in Power BI Desktop
Before you even publish to the service, you should do your initial testing locally in Power BI Desktop. This gives you a quick way to spot obvious errors in your DAX expressions and role setup. The feature for this is called "View as".
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.
How to Use "View as" in Power BI Desktop
Follow these simple steps to simulate how a user assigned to a specific role will see the report:
- With your report open, go to the Modeling tab in the ribbon.
- Click on View as.
- A dialog box will appear showing the roles you've created. Select a role to test it. For example, if you have a "Regional Manager - North" role, select it.
- You can also test a combination of roles if a user might belong to more than one.
- Click OK.
Instantly, your report canvas will update to show you exactly what a user in that role would see. You'll see a yellow banner at the top of your report confirming which role you are viewing as (e.g., "Now viewing as Regional Manager - North"). To stop the simulation, just click Stop viewing on that yellow banner.
Why This Desktop Check is Useful
This is your first line of defense. It helps you confirm that your basic DAX logic is sound and that the filters are being applied as expected. However, it has one major limitation: it doesn't test the actual security in the Power BI Service with real user accounts. It only simulates the role, which is why testing in the Service itself is so important.
Part 2: The Main Event - How to Test RLS in the Power BI Service
Once you've published your report and its underlying dataset to a workspace, the real testing begins. This is where you verify what your end-users will experience when they access the report through their own work accounts.
The process involves two key stages: assigning users to your security roles and then using the "Test as role" feature.
Step 1: Assign Users or Groups to Your Security Roles
First, you need to tell Power BI which users belong to which RLS roles. A best practice here is to use security groups from Microsoft Entra ID (formerly Azure Active Directory) rather than assigning individual user emails, as it makes long-term management much easier.
- Navigate to the workspace where you published your content.
- Find your dataset (it will have the orange dataset icon). Don't click the report, click the dataset.
- Click the three dots (...) next to the dataset name and select Security.
- This will open the Row-Level Security page. You’ll see the list of roles you created in Power BI Desktop.
- Select a role, and a text box will appear. Start typing the name of the user or security group you want to assign to this role.
- Click Add, then make sure to click Save.
Repeat this process for all your roles, assigning the appropriate users or groups to each one. Now your security is live.
Step 2: Use "Test as role" in the Service
Now that your users are assigned, you can test their view. This is the most reliable way to check RLS in Power BI.
- On that same Row-Level Security page for your dataset, click the three dots (...) next to the role name you want to test.
- Select Test as role.
Power BI will immediately open the published report in a special test view for that role. Just like in Desktop, a banner will appear at the top, but this time it’s blue, confirming what you're testing (e.g., "Now viewing report using role 'Regional Manager - North'"). Click through the report pages to ensure all visuals are filtered correctly.
Testing a Specific User's View (Crucial for Dynamic RLS)
What if you want to be 100% certain what a specific person, say emilyc@yourcompany.com, will see? This is especially important for dynamic RLS that uses DAX functions like USERPRINCIPALNAME() to filter data based on the logged-in user.
- While you are in the "Test as role" view, you'll see an option in the blue banner for "Viewing as...".
- Select the option Person.
- Type the full email address of the user you want to impersonate into the text field (e.g., emilyc@yourcompany.com) and click Apply.
The report will now precisely simulate the view for that specific user, applying both the RLS role filter and any dynamic filters associated with their email address. This is the ultimate proof that your security model works as intended.
Practical Tips and Common Gotchas
Testing RLS is straightforward, but a few common issues can trip people up. Keep these in mind to save yourself some troubleshooting headaches.
Workspace Roles Trump RLS Rules
This is the most common mistake. RLS rules do not apply to users with Admin, Member, or Contributor roles in the workspace. These users will always see all the data, regardless of any RLS roles you assign them to. Row-Level Security is enforced only for users who have the Viewer role in the workspace. So, if your "test user" is also the Admin of the workspace, your testing won't work - you'll always see everything.
Check Your Data Model Relationships
RLS works by filtering tables. For those filters to propagate correctly, the relationships in your data model need to be set up properly. Ensure that you have the right relationships in place between your fact tables and your dimension/lookup tables (like your employee or region tables), and make sure the filter directions are set to "single" or "both" as needed for your model.
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 RLS and USERPRINCIPALNAME()
When using dynamic RLS, the USERPRINCIPALNAME() DAX function returns the user's email login (e.g., emilyc@yourcompany.com). Your employee table must have a column that contains this exact email format for the filtering to work. A common error is having only usernames (like "emilyc") in the table, which won't match.
"Sharing" vs. Workspace Access
If you don't add users to the workspace with the Viewer role but instead share the report with them directly, they are granted permission to view it. RLS will be applied for these users as well. The key is that they must not have elevated Admin, Member, or Contributor permissions at the workspace level for their RLS filters to take effect.
Final Thoughts
Verifying your Row-Level Security in the Power BI Service isn't an optional step, it's a critical part of the report deployment process that ensures data is both secure and correctly displayed for your users. By testing first in Desktop and then thoroughly in the Service using the "Test as role" feature, you can confidently share your reports knowing your data's integrity is protected.
Power BI is an incredible tool, but setting up security, managing user lists, and validating complex data models still involves a lot of manual configuration. At Graphed, we felt this friction firsthand. Our goal is to remove these technical hurdles. We built an AI-powered data analyst that connects to your key data sources - from marketing platforms to sales CRMs - and lets you build reports and dashboards just by describing what you want to see in plain English. There's no need to manually manage complex roles and permissions in the same way because you can generate and share specific insights on-demand, giving the right people just the information they need in seconds.
Related Articles
Facebook Ads for Massage Therapists: The Complete 2026 Strategy Guide
Learn how massage therapists can use Facebook ads to attract new clients, build brand awareness, and fill their booking calendar in 2026.
Facebook Ads for Window Cleaners: The Complete 2026 Strategy Guide
Learn how to use Facebook ads to generate consistent leads for your window cleaning business in 2026. This complete guide covers targeting, ad types, budgeting, and optimization strategies.
Facebook Ads For Pet Stores: The Complete 2026 Strategy Guide
Learn how to run profitable Facebook ads for pet stores in 2026. Discover hyper-local targeting strategies, audience insights, and creative frameworks that drive results.