Power BI governance: row-level security, workspaces and access
Power BI governance is the set of rules that decide who can build, publish and see what. For large organisations it covers workspace structure and roles, row-level security so each person sees only their slice of data, sensitivity labels that protect exports, endorsed or certified semantic models as the trusted source, and audit logs. It matters more now because Copilot and data agents answer questions from the same models, so access rules must be right before AI is switched on.
Why does Power BI governance matter?
Power BI spreads quickly. Within a year, many organisations have hundreds of workspaces, several versions of the same model and reports shared by link with people who should not see them. Governance brings order without stopping people from working: it defines where content lives, who can change it, who can see which data and which models are trusted. With Copilot and data agents answering questions from the same models, weak access rules now show up in AI answers as well as in reports.
How should workspaces be organised?
Use deployment pipelines to move content from development to test to production, so changes are reviewed before readers see them. Publish to readers through Power BI apps rather than giving them access to workspaces.
Who should have which role?
| Role | Typical holder | Can do |
|---|---|---|
| Admin | BI platform owner | Manage access and settings |
| Member | Lead report authors | Publish and share content |
| Contributor | Report authors | Create and edit content |
| Viewer | Rarely used directly | Read content; prefer apps for readers |
Assign roles to security groups, not individuals, so access follows people when they join or leave a team. Review group membership every quarter.
How does row-level security work?
Row-level security (RLS) adds filters to a semantic model so each user only sees the rows they are allowed to. You define roles in the model, for example “Region”, with a filter that matches the user’s region, then map security groups to roles in the service. Microsoft documents the steps in its row-level security guide. RLS applies wherever the model is used: reports, Analyze in Excel, Copilot answers and data agents. Object-level security can also hide whole tables or columns, such as salary fields.
- Define roles in the model: Region, branch, team or customer type.
- Use dynamic rules: Filter by the signed-in user, looked up from a mapping table.
- Map groups to roles: Assign security groups, not individuals.
- Test as each role: Use “view as” to check what each role sees.
- Review regularly: Check mappings when teams or regions change.
How do sensitivity labels help?
Microsoft Purview sensitivity labels mark reports and models as, for example, Confidential. The label travels with data exported to Excel, PDF or PowerPoint, so protection does not stop at the browser. Admins can require labels on new content and apply them automatically from upstream data. For banks and telecom operators handling customer data, labels are often a compliance requirement.
How do people know which model to trust?
- Promote: Owners mark a model as ready for wider use.
- Certify: A small group of reviewers marks models as the official source.
- Describe: Every certified model has descriptions for tables, columns and measures.
- Own: Each model has a named business and technical owner.
- Retire: Old or duplicate models are archived on a schedule.
Certified models are also the right place to point Copilot, because their names and descriptions are maintained. See Copilot in Power BI.
What changes when you add AI?
Before switching on Copilot, check RLS on every model in scope, hide fields that readers should not query, and confirm the tenant setting is limited to the right groups. In our Mashreq NEO project, the dashboards and the private AI assistant shared one governed data model, role-based access and an AI layer that only reads documents each user is allowed to see.
What should you monitor?
Use the Power BI activity log and admin monitoring to track who views, exports and shares content. Watch for reports shared outside the organisation, large exports and workspaces with no recent activity. The Power BI implementation planning guidance from Microsoft covers auditing and tenant settings in depth.
Where should you start?
- Name a platform owner: One person accountable for tenant settings and standards.
- Agree a workspace pattern: Domains, stages and apps.
- Secure the top models: Add RLS and labels to the models with sensitive data first.
- Certify a few models: Start with the ones leadership relies on.
- Write it down: A short governance page everyone can find.
How UIUX Studio helps
We set up governed Power BI platforms for banks, telecom operators and enterprises, from workspace design to row-level security and AI readiness. See our Technology Advisory service, or read about Power BI for banks and Microsoft Fabric.
Frequently asked questions
Does row-level security apply to Copilot?
Yes. Copilot answers respect the model’s RLS for each user.
Should readers get workspace access?
Usually not; share through apps instead.
Can RLS hide whole columns?
No, that is object-level security; RLS filters rows.
Do labels protect exports?
Yes. Sensitivity labels travel with exported files.
Who should certify models?
A small, named group agreed by the platform owner.