How to Implement Page Level Security in Power BI

Tired of showing your entire Power BI report to every single user? Page Level Security (PLS) is your solution for creating custom report experiences, ensuring users only see the pages relevant to them. This guide will walk you through a practical, step-by-step method to implement PLS and deliver a tailored view for each person on your team.

What is Page Level Security in Power BI?

Page Level Security is a design technique used in Power BI to control which report pages a user can access. Unlike its cousin, Row Level Security (RLS), which filters the data within a page, PLS hides entire pages from view. This means you can build one comprehensive report and then dynamically show or hide specific pages based on who is viewing it.

Why would you do this? Consider these common scenarios:

• Sensitive Information: An HR dashboard might contain a public "Company Holidays" page and a secure "Executive Compensation" page. You can use PLS to hide the compensation page from everyone but the executive team.

• Department-Specific Views: Your sales team needs to see the "Sales Pipeline" and "Regional Performance" pages, while the marketing team only needs the "Campaign ROI" and "Lead Generation" pages. PLS can present the right view to each team from a single report.

• Simplified User Experience: Instead of overwhelming new users with ten different pages, you can create a simplified view that only shows them the two or three pages they actually need for their job.

The Core Concept: A Secure Navigation Hub

Unlike RLS, Page Level Security isn't a built-in feature with a dedicated settings menu. It's a method you implement by combining a few powerful Power BI features - hidden pages, bookmarks, and DAX measures - to build your own secure navigation system. In essence, you hide all the sensitive pages and then create a single, visible "Home" page that acts as a secure menu, only showing links to the pages a user is authorized to see.

Let's get started building it.

Step 1: Hide The Pages You Want to Secure

Your first step is to hide any pages you want to control access to. When a page is hidden, it won’t appear in the navigation bar on the left side when you publish the report to the Power BI service. This prevents users from simply clicking through to a page they shouldn't see.

In Power BI Desktop, simply right-click the tab of the page you want to secure and choose Hide Page. You’ll see a small “eye” icon with a slash through it, indicating the page is now hidden. Repeat this process for all pages you want to include in your secure navigation.

Step 2: Create a Bookmark for Each Hidden Page

Bookmarks in Power BI capture the current state of a report page. We'll use them to create a direct link to each of our hidden pages that we can trigger with a button later.

1. Navigate to the hidden page.

2. Go to the View tab in the ribbon and click Bookmarks to open the bookmarks pane.

3. Once on the page you want a bookmark for, click Add in the bookmarks pane.

4. Rename the bookmark descriptively. It's a best practice to name it exactly the same as the page itself, for example, "Sales Dashboard" or "Marketing ROI."

5. Click the ellipsis (...) next to the new bookmark and uncheck Data. This ensures the bookmark only handles navigation and doesn't unexpectedly change filters or slicers when a user clicks it.

Repeat this for every hidden page you want to control access to, creating a one-to-one mapping between hidden pages and bookmarks.

Step 3: Create Your Security and Navigation Table

This table is the brains of your entire security setup. It will define who can see what. At a minimum, this table needs two columns: the user's email address (what Power BI calls the User Principal Name, or UPN) and the name of the page they have access to.

You can create this table in Excel and import it, pull it from a SQL database, or for smaller projects, enter the data directly into Power BI.

To create it in Power BI:

1. Go to the Home tab and click Enter data.

2. Create two columns: UserEmail and PageName.

3. Fill in the table. The UserEmail must be the exact email address the user logs into Power BI with. The PageName should exactly match the names of the bookmarks you created in the last step.

Here’s what your table might look like:

In this example, the manager can see two pages, the analyst can see one, and the marketing professional sees an entirely different one. After creating the table, name it something like "Page Security" and click Load.

Step 4: Create the "Gatekeeper" DAX Measure

Now, we need to create a DAX measure that will act as a gatekeeper. This measure will check the email of the person currently viewing the report and see if they have access to a specific page based on our security table.

1. Go to the Home tab and click New measure.

2. Enter the following DAX formula into the formula bar:

Let's break this down:

• USERPRINCIPALNAME(): This is a special DAX function that automatically returns the login email of the current user viewing the report in the Power BI Service.

• SELECTEDVALUE('Page Security'[PageName]): This grabs the page name from the context of whatever visual we use it in (which we'll set up in the next step).

• The formula then counts the rows in your Page Security table where both the user's email and the selected page name match. If it finds a match (count > 0), it returns 1. If not, it returns 0.

Step 5: Build Your Dynamic Navigation Page

Create a new, visible report page called "Home" or "Navigation." This is the first page your users will land on. On this page, we'll build a navigation menu that dynamically displays links based on our security setup.

1. On your "Home" page, add a Slicer visual from the Visualizations pane.

2. Drag the PageName column from your Page Security table into the “Field” well of the slicer. You’ll see a list of all your page names.

3. With the slicer visual selected, go to the Filters pane. Drag your new DAX measure, IsPageVisible, onto the "Filters on this visual" section.

4. Expand the filter settings, choose "is" from the dropdown, and enter "1" into the box. Click Apply filter.

Magically, the slicer will now dynamically filter itself! When manager@yourcompany.com views the report, this slicer will only show "Sales Dashboard" and "Regional Deep Dive." When marketing@yourcompany.com views it, the slicer will only show "Marketing ROI." We've created a personalized menu!

Step 6: Configure a “Go” Button to Navigate

We have a dynamic menu, but clicking the names in the slicer doesn't do anything yet. We need a button to take the user to the bookmarked page they've selected.

1. First, we need one more small measure that captures the user’s slicer selection. Create a new measure with this DAX formula:

1. Now, insert a button on your "Home" page by going to Insert > Buttons > Blank. Customize it to say something like "Go to Page."

2. With the button selected, go to the Format pane and turn Action on.

3. Expand the Action section. For Type, choose Bookmark.

4. For Destination, do not pick a bookmark from the list. Instead, click the fx (Conditional formatting) button.

5. In the popup window, under "Based on field," select the SelectedPageNavigation measure you just created. Click OK.

This setup wires our button's action to whatever value the user has selected in the slicer. Now, a user can select a report from their personalized list and click the "Go" button to be taken directly to the correct hidden page.

Step 7: Crucial Final Step – Testing!

Once you've set this all up, you must test it to ensure it works correctly. You can do a basic test in Power BI Desktop:

1. Go to the Modeling tab and click View as.

2. Check the box for Other user and enter one of the email addresses from your security table (e.g., analyst1@yourcompany.com).

3. Click OK. Your report will now simulate that user's view, and you should see the navigation slicer update accordingly.

The most important test, however, is publishing the report to the Power BI Service and having actual users (or test accounts) with different permission levels open it and confirm they only see the page links they are supposed to.

A Note on PLS and RLS

Remember, PLS controls navigation. It prevents users from easily getting to a page. However, it does not secure the underlying data for that page. For ultimate security, especially for highly sensitive data, it's best to use PLS and RLS together. That way, even if a user found a direct link to a hidden page, RLS would still ensure they can't see any data they aren't authorized to view.

Final Thoughts

Implementing Page Level Security is a transformative technique that takes your Power BI reports from static documents to dynamic, personalized applications. By combining hidden pages, bookmarks, and a bit of DAX, you can build a more secure and user-friendly experience that tailors the report to each person's role.

While mastering these types of configurations in tools like Power BI is a valuable skill, it can be time-consuming. We built Graphed to remove this kind of complexity. Instead of wrestling with security tables and DAX, our platform allows you to connect all your data sources and create secure, real-time dashboards using simple, plain English - in seconds, not hours. Empowering your team with data becomes as easy as asking a question.