Problem Statement: Currently, Power BI only offers Row-Level Security (RLS) to control data access, but there's no native way to control which report pages users can see in the navigation pane. All users with report access can view all pages, even if those pages aren't relevant to their role.
Requested Feature: Implement Page-Level Security (PLS) that allows report developers to:
- Define which user roles can access specific report pages
- Automatically hide pages from the navigation pane for users without access
- Prevent unauthorized users from manually navigating to restricted pages
Business Use Case: Many organizations have reports with different sections for different audiences:
- Executive dashboards for leadership
- Detailed financial analysis for finance teams
- Operational metrics for operations staff
- HR metrics for HR department
Currently, we must create separate reports or apps for each user group, leading to:
- Content duplication and maintenance overhead
- Multiple versions of similar reports to manage
- Increased workspace clutter
- Higher administrative burden
Proposed Solution:
- Add a "Page Security" setting similar to RLS in Power BI Desktop
- Allow assignment of security roles to individual pages
- In Power BI Service/Apps, only display pages the user has permission to view
- Integrate with existing RLS roles for unified security management
Benefits:
- Simplified report management (one report instead of many)
- Better user experience (users only see relevant content)
- Reduced administrative overhead
- Consistent with existing RLS security model
- More scalable enterprise deployment
Alternative Considered: Creating multiple reports/apps works but creates significant maintenance challenges and doesn't scale well for large organizations with many user roles.
4 Comments
- these can be fairly easily done using the technique of 'obfuscation'. - it DOES rely on the dashboard designer hiding all but hteh cover page initially, - then holding a table with exact page names From there - applying a set of measures to bring through the page name (this can use a varying degree com complexity dependant upon your own UAM), returning either a blank or different pages as per that model. Applying these to individual buttons where required gives the 'impression' that the report is tailored to the individual viewing it through Workspace and using the RLS controls in place. You could also use OLS (Object Level Security) via something like Tabular Editor .. but that does have a tendency to make things appear 'broken'
arpostPost Prodigy
Would love to see conditional page logic. While there are "hacky" ways to do this, they aren't ideal and either require developers to abandon native Microsoft UI (e.g., create custom page navigation UI inside report) or instruct users "just don't click that". The custom UI eats up precious real estate, so having the ability to just conditionally define page access options would be great.
This can be separate from (though integratable with) RLS as there can be places where you don't have RLS in a report but do want PLS (page-level security).
- the solution will make ui ugly or hacky from the url so need proper solution which is really secure
101MathewAdvocate V
obfuscation - is not security, and pages can still be accessed, if you know how. Page Level Security would give many benefits as outlined by the author - Sometime your not operating via Apps - and Page Level Security for a report is needed, (as outlined above) - this idea has been floating about for a while under the following ideas https://community.fabric.microsoft.com/t5/Fabric-Ideas/Page-Level-security-in-reports/idi-p/4606366 (this one appears to have the most votes) The earliest version of this idea that I can find (quickly) is back in 2021 https://community.fabric.microsoft.com/t5/Fabric-Ideas/Page-level-security/idi-p/4497912 It would be great if all the idea for Page Level Security could be combined into one
