How to Restrict Access to Power BI Reports

Sharing your Power BI report with the team gives everyone access to valuable insights, but sharing it with absolutely everyone can be a data governance nightmare. You need to control who sees what, especially when dealing with sensitive information like sales performance, financial data, or customer details. This article breaks down exactly how to restrict access in Power BI using workspaces, roles, and row-level security so you can share your data confidently.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Why Securing Your Power BI Reports Matters

Before jumping into the "how," it's worth understanding the "why." Properly managing access isn't just a box-ticking exercise, it’s essential for several reasons:

• Data Privacy and Compliance: Regulations like GDPR and CCPA have strict rules about personal data. Limiting access ensures that only authorized personnel can view sensitive customer or employee information.
• Confidentiality: Not every report is for every eye. Financial projections, sales-team leaderboards, and executive-level summaries should be kept within their intended audiences.
• Data Integrity: Controls prevent well-intentioned but untrained users from accidentally editing or deleting critical reports, datasets, or dashboards.
• Clarity and Focus: When users only see the data relevant to their role, they can focus on the insights that matter to them without getting lost in noise. A sales rep in California doesn't need to see the numbers from the New York office.

Good security isn't about locking data away, it's about delivering the right data to the right people at the right time.

The Foundation: Understanding Workspaces and Roles

The first layer of security in Power BI is the workspace. A workspace is a collaborative container where you can group related dashboards, reports, workbooks, and datasets. Think of it as a shared folder for your BI content. Access is managed through four distinct roles:

• Admin: Has full control. Admins can add or remove other users (including other Admins), publish or unpublish apps, and manage all content within the workspace. This role should be reserved for a select few.
• Member: Almost as powerful as an Admin. Members can add other users (but not Admins), publish apps, and manage content. They have broad permissions and can be considered co-owners of the workspace.
• Contributor: This role is for people who create and edit content. Contributors can create, edit, and publish reports and datasets within the workspace but cannot publish or update the app, or add other users. This is a common role for data analysts or departmental Power BI champions.
• Viewer: This is a read-only role. Viewers can see and interact with reports and dashboards (e.g., use filters and slicers) but cannot make any changes. This is the perfect role for the majority of data consumers in your organization who just need to view the final insights.

Assigning roles is straightforward. When you're in your workspace in the Power BI Service, simply click "Access" at the top and add users by email, giving them the appropriate role. Using Active Directory security groups here instead of individuals is a highly recommended best practice, as it makes managing access much easier as your team grows or changes.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Granular Control with Row-Level Security (RLS)

Workspace roles are great for controlling who can access a report, but what if you need to control what <em>data they see inside</em> that report? For example, imagine you have a single sales report for the entire company, but you want sales managers to only see their team's data, and individual sales reps to only see their own personal numbers. Recreating the report dozens of times is inefficient and unwieldy.

This is where Row-Level Security (RLS) comes in. RLS allows you to create a single report that dynamically filters its data based on who is viewing it.

Setting Up Static RLS in Power BI Desktop

Static RLS involves defining fixed rules for different groups of users. Let's use our sales team example. We want to create a role so that a manager can only see sales data for the "USA" region.

Here’s how you do it:

1. Navigate to the Modeling tab in the ribbon at the top of Power BI Desktop.
2. Click on Manage Roles. A new window will pop up.
3. In the "Manage roles" window, click Create. Name your role something descriptive, like USA Sales Manager.
4. Select the table you want to apply the filter to (e.g., a "Sales" table). In the "Table filter DAX expression" box on the right, you need to write a simple DAX formula. DAX is Power BI’s formula language, similar to what you might use in Excel.
5. Click the Save button.

Testing Your RLS Role

Before you publish, it's crucial to test your new role to make sure it works as expected. In the Modeling tab, click on View as. In the "View as roles" window, check the box next to your new USA Sales Manager role and click OK. Your report will immediately refresh, and all your visuals will now only show data for the USA region. You’ll see a yellow bar at the top of your report confirming you're viewing the report as that role.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Scaling Up with Dynamic RLS

Static RLS is great for a few roles, but it doesn't scale well. What if you have 50 different regions or hundreds of sales reps? Creating a static rule for each one would be a nightmare.

Dynamic RLS solves this by basing the filter on the user’s login credentials. It uses DAX functions to find out who is logged in and applies the appropriate filter automatically. You set up the rule once, and it works for everyone.

Here’s the setup:

1. Your model needs a lookup table that maps users to what they can see. For instance, you could have a "Sales Reps" table with columns for their name, their assigned region, and their email address (which they use to log into Power BI). This user table should have a relationship with your main data table (e.g., the "Sales" table).
2. Go to the Modeling tab > Manage Roles.
3. Create a new role. Let’s call it Dynamic Sales Role.
4. Select the lookup table (our "Sales Reps" table). In the DAX expression box, enter the following formula: [EmailAddress] = USERPRINCIPALNAME()
5. Click Save.

The magic here is the USERPRINCIPALNAME() function. When a user logs into Power BI Service, this function returns their email address. The rule then filters the "Sales Reps" table down to just the row matching that user. Because of the relationship between your "Sales Reps" table and your "Sales" data, this filter automatically propagates through your model, showing the user only the data associated with them.

Don't Forget: Assign Users in Power BI Service

Creating RLS rules in Power BI Desktop only defines them, it doesn't apply them to anyone. You have to assign users to your roles after publishing the report to the Power BI Service.

1. Publish your report to a workspace.
2. In the Power BI Service, find the dataset associated with your report (it will have the same name).
3. Click the three dots (...) next to the dataset and select Security.
4. You’ll see a list of the roles you created in Desktop (e.g., USA Sales Manager or Dynamic Sales Role).
5. Select a role and start typing the email addresses or security groups of the users you want to assign to it.

Now, when those users open the report, the RLS rules will be applied, and they will only see the data they're authorized to see.

Sharing and Distributing Content Securely

Once your row-level security is set, you need to distribute the content. RLS works hand-in-hand with standard sharing mechanisms.

Using the Share Button

The simplest way to share is the "Share" button at the top of a report or dashboard. You can share with individuals or security groups. When you use this method, the recipients get a link to view the content. They can't edit it, but you can grant them permission to re-share or even build their own new content using the underlying dataset.

Graphed

Still Building Reports Manually?

Watch how growth teams are getting answers in seconds — not days.

Watch the Demo

Publishing a Power BI App

For broader distribution within an organization, publishing a Power BI App is the best practice. An app bundles related reports and dashboards into a professional, easy-to-navigate package. It separates you, the creator, from the consumer.

When you create an app from a workspace, you get a dedicated "Permissions" tab where you can specify exactly who has access to the app - either the entire organization, specific individuals, or security groups. This simplifies access management because you manage permissions once for the entire collection of content. Users who have access via the app automatically have "Viewer" permissions, and any RLS roles you’ve defined will work seamlessly.

Final Thoughts

Securing your Power BI reports is a critical skill for any data professional. It's all about using the right layer of control for the job, whether it's workspace roles for broad permissions, RLS for fine-grained data filtering, or apps for clean and managed distribution. By mastering these methods, you can confidently share powerful insights across your organization without compromising sensitive data.

Managing user permissions is a necessary step, but it’s often one of many hurdles that keep teams from getting the answers they need quickly. We built Graphed because we believe getting business-critical insights shouldn't be so complicated. By using natural language, anyone on your team can connect to data sources like Google Analytics or Shopify and instantly create dashboards and reports, letting them focus on making decisions instead of wrestling with tool configurations.