Power BI has revolutionized how organizations visualize and interact with data. One of the most critical aspects of data management in Power BI is ensuring that users only access data relevant to them. While row-level security is widely used to control data access within reports, there are cases where we need to restrict access to entire pages of a report.Â
In this blog, we will explain the concept of page-level security in Power BI, its use cases, how to implement it, and its limitations, and answer some frequently asked questions.
Use Case
Imagine a complex Power BI report that contains various pages from different departments within your organization, such as Sales, Operation, HR, etc. The Finance team should only have access to the Finance page, while the HR team should only see the HR page. However, the admin/management should have access to all pages. This scenario calls for page-level security, ensuring that each user group can only view the pages relevant to them, thus maintaining data privacy and relevance.
How to Implement Page-Level Security
Although Power BI doesn’t have a native feature for page-level security, you can achieve this effect using a combination of row-level security, Slicer & navigation buttons. Here’s how:
1. Creating a Security Table
We need to create a table called Security with the column name User containing the mail ID of all users and one more column, Page, containing the name of the pages that need to be accessible for that user. Then, load this table into your Power BI model.
2. Create User Roles
Next, create roles to manage page-level access. Go to the Modeling tab and select Manage Roles. Click Create, then name the role ‘Page Security’. Apply a filter to the Security table. In this example, add a filter for the User column and implement row-level security on the Security table using the DAX function USERPRINCIPALNAME(). This setup ensures users can only view data corresponding to their assigned role.
'Security'[User]=USERPRINCIPALNAME()
3. Creating a Slicer and a Navigation Button
To facilitate navigation, create a measure named Navigation that captures the value selected in the Page slicer.
Navigation = SELECTEDVALUE('Security'[Page])
Next, add a slicer using the Page column from the Page table. Place an image or button beside the slicer, like a Right arrow button, and configure it to execute a page navigation action. Use the Navigation measure for conditional formatting to control the button’s visibility.
4. Hide All Pages Except the Main Landing Page and Add 'Back' Button on Hidden Pages
Set Initial Page Visibility:
Hide all pages except the main landing page to ensure only the landing page is visible when users first access the report.
Add 'Back' Button:
On each hidden page, insert a Back button.
Go to the Insert tab, select Buttons, and choose a button style (e.g., Back Arrow).
Configure the button action by enabling Action and setting it to Page Navigation, then link it to the main landing page.
5. Testing the Setup From the Role’s Perspective
To view how the dashboard appears to Nick, select View as, check the appropriate boxes per the image, and enter Nick’s email address. Notice that the Sales and Operations pages are not visible, demonstrating the effectiveness of page-level security.
6. Publish and Share
Publish the report to the Power BI service and share it with the respective users, ensuring that roles are correctly assigned.
What are the Limitations of Page Level Security?
No Native Support: Power BI doesn’t provide an out-of-the-box solution for page-level security, so this method requires creative use of existing features.
Maintenance: Managing complex reports with multiple roles and bookmarks can become cumbersome, especially if the report structure changes frequently.
Page-level security does not function as expected when using Drill through functionality in your report.
If a user receives the URL of a hidden page from someone else, they can access the restricted content.
User Experience: This approach might introduce additional user navigation steps, potentially impacting the overall user experience.
Security Risks: If not implemented correctly, users might gain access to restricted pages or data. Ensuring that all pages are correctly hidden and that navigation controls are properly managed is crucial to maintaining security.
Performance Impact: Extensive use of bookmarks and dynamic navigation can impact the report’s performance, especially if it includes many interactive elements or large datasets.
Closing
Implementing page-level security in Power BI is essential for organizations that must ensure data privacy and role-based access within a single report. Although it requires a workaround involving row-level security, Slicer, and dynamic navigation, the outcome is a tailored and secure reporting experience for your users. By understanding and applying these techniques, you can maintain a high level of control over your data access, enhancing the overall effectiveness of your Power BI reports.
If you have questions or need assistance implementing page-level security in Power BI, please contact phData.
FAQs
What happens if a user tries to access a restricted page directly via a URL?
If users have direct access to the Power BI report via a URL, they might be able to see the page. To prevent this, ensure that pages are hidden and can only be accessed via buttons controlled by security measures.
Can I use Power BI's built-in security features for page-level security?
No, Power BI does not have a built-in feature specifically for page-level security. However, you can achieve similar functionality using row-level security, bookmarks, and navigation buttons.
Is page-level security suitable for large reports with many user roles?
Page-level security can be challenging to manage in large reports with many user roles due to the complexity of maintaining multiple bookmarks and navigation paths. It’s important to weigh the benefits against the potential maintenance overhead.
