Power BI Governance: Row-Level Security, Workspaces, and Why IT and Business Must Align

How Power BI governance works in practice. Row-level security, workspace design, sensitivity labels, and content endorsement. Lessons from Day 3 of Microsoft Power BI training.

Share

On the last day of a three-day Microsoft Power BI Data Analysis Professional course, something happened that does not happen very often in technical training.

The business users in the room asked to schedule a meeting with IT.

Not because something went wrong. Because they finally understood enough to know what questions to ask. That moment, more than anything else from the week, captures what a well-executed analytics training program can do for an organization.

This is Part 3 of a three-part series. Read Part 1: Data Preparation and Part 2: DAX, Semantic Models, and Governance.

How Power BI Row-Level Security Actually Works

In my Day 2 recap, I mentioned that a stakeholder raised a question nobody in the room could fully answer: when you publish a report from a semantic model, how do you make sure that people who should not see certain data cannot see it?

Day 3 answered that question. The answer is not a single feature. It is a layered governance architecture, and understanding how the layers work together is one of the most important things any organization can do before it rolls out Power BI at scale.

Here is how the layers break down.

Layer 1: Workspace Roles

In the Power BI Service, workspaces are where reports, dashboards, and semantic models live. Every person who has access to a workspace is assigned one of four roles:

  • Admin: Full control over the workspace and its content
  • Member: Can manage the workspace and publish content
  • Contributor: Can create and publish content but cannot manage settings
  • Viewer: Can only read and interact with published content

This is your first line of access control, and it operates at the workspace level.

Layer 2: Row-Level Security (RLS)

Row-level security is the most directly relevant layer to the Day 2 question. RLS allows you to filter the data that specific users can see within a report, based on their identity.

A finance director who opens a report sees the numbers for the entire organization. A department manager who opens the same report sees only their department's numbers. The report looks the same. The data behind it is filtered automatically based on who is logged in.

RLS is configured in Power BI Desktop before a report is published. You define roles, assign them to tables in your data model, and write filter expressions using DAX. Once the semantic model is published to the Power BI Service, you assign users or security groups to those roles. From that point forward, the filtering happens automatically. The user never knows they are seeing a restricted view. They just see what they are supposed to see.

Layer 3: Sensitivity Labels

Organizations with Microsoft Purview can apply sensitivity labels to reports, dashboards, semantic models, and dataflows. Labels like Confidential or Highly Restricted notify users when they are working with sensitive content and apply protections when that content leaves the Power BI Service, such as when it is exported to Excel or PowerPoint. The label travels with the content, not just the container.

Why All Three Layers Matter

These three layers working together form a complete governance framework for enterprise reporting:

  • Workspace roles control who gets in the door
  • Row-level security controls what data they see once inside
  • Sensitivity labels protect content when it moves outside Power BI

No single layer is sufficient on its own. All three together are what makes Power BI deployable in an environment with real data privacy requirements.

In a medallion architecture, these Power BI governance controls sit on top of the data platform's own security layers. The Gold layer should already have governance applied before data reaches the semantic model. Power BI's security becomes a second layer of protection, not the only one.

Power BI Workspace Design: An Organizational Decision, Not a Technical One

The reaction in the room when we got to workspaces was immediate. Business users started asking questions they had never thought to ask before:

  • Who should own a workspace?
  • How many workspaces do we need?
  • If two departments share a workspace, who decides what gets published there?

These are exactly the right questions. And they are not questions IT can answer alone.

A workspace in Power BI is essentially a container for collaboration and content management. It holds semantic models, reports, and dashboards, and it defines who can do what with them. But how you organize workspaces across an organization requires decisions about department boundaries, data ownership, content governance, and sharing policies. Those decisions involve business stakeholders, not just technical architects.

The Most Common Workspace Mistake

The most common mistake organizations make is letting workspaces grow organically. One team creates a workspace for a project. Another team creates one for their department. A third creates one for a specific report. Within months, the organization has dozens of workspaces with no consistent naming convention, no clear ownership, and no visibility into what content exists where.

The better approach is to define a workspace strategy before Power BI is deployed at scale. That means deciding:

  • How workspaces will be organized (by department, by project, by data domain)
  • Who will be designated as workspace owners
  • What content belongs where
  • How access will be managed over time

It is a governance conversation, and it needs to happen between IT and the business before the first workspace is created.

The fact that the business users in the training recognized this and asked for that conversation is a sign of a maturing analytics culture. They were not just learning a tool. They were starting to think about how to govern it.

Content Endorsement: Knowing Which Reports to Trust

One feature that generated real interest in the room was content endorsement. In the Power BI Service, workspace owners can endorse semantic models and reports in two ways:

  • Promotion signals that content is high quality and worth using
  • Certification signals that content has been reviewed, meets organizational standards, and is authoritative

This matters enormously in large organizations. When dozens of reports exist across multiple workspaces, users need a way to know which ones are official and which ones are works in progress. Without endorsement, every report looks the same. With it, the reports that leadership should be relying on are clearly marked.

Content endorsement is a small feature with a large organizational impact. It is how you scale trust across a self-service analytics environment. And it connects directly to the point raised on Day 1 about design standards: just as consistent visual design signals credibility, certified content signals authority.

What This Power BI Training Revealed About IT and Business Alignment

Stepping back from the individual features and lessons, what this three-day course demonstrated most clearly is that a successful Power BI deployment is a shared responsibility between IT and the people who use the data.

IT understands the architecture, the security framework, the workspace design, and the data pipeline. Business users understand the requirements, the decisions they need to make, and the questions they need the data to answer. Neither group can do this alone.

The problem in most organizations is that these groups operate separately until something goes wrong. IT builds the infrastructure. Business users build reports. At some point the reports contradict each other, or sensitive data shows up somewhere it should not, or a workspace becomes impossible to manage because no one planned for governance from the start.

The business stakeholders in this training spent three days learning what Power BI actually requires to work well. By the end, they understood enough to know that the conversation with IT needed to happen before they started publishing reports, not after.

For organizations preparing to roll out Power BI, or for those already in the middle of a deployment that is not going as planned, the most valuable investment you can make is getting IT and the business in the same room before the tool goes live:

  • Define the workspace strategy together
  • Agree on data ownership
  • Establish the governance framework
  • Decide what gets certified and who certifies it

The technology is mature enough. The governance practices are where most organizations still have work to do.

Connecting to the Unified Data Platform

All three days of this training connected directly to the unified data platform project I have been working on at a major university. We are consolidating six departments onto Microsoft Fabric, with Power BI as the reporting layer. The questions raised in this classroom, about workspace design, role-based access, row-level security, and data governance, are not hypothetical for us. They are the decisions we are working through right now.

What this training reinforced is that the technical build and the governance design have to happen in parallel. You cannot finish the architecture and then figure out governance. By the time you get there, the decisions that would have shaped the architecture are already locked in.

If your organization is on a similar path, the time to have these conversations is before the first report goes live. The framework is there. The tools support it. The missing piece, almost always, is the organizational alignment to use them well.

The Outcome That Matters Most

At the end of three days, the business stakeholders in this training left feeling empowered. Not just trained on a tool, but genuinely confident in their ability to build valuable Power BI reports for their business units and for the university as a whole.

That is the outcome worth measuring. Not how many features were covered or how many hands-on exercises were completed, but whether the people in the room walked out ready to do something with what they learned.

That kind of empowerment does not happen by accident. It comes from training that connects the technical to the practical, that treats business users as capable professionals rather than passive recipients of IT decisions, and that gives people enough context to ask the right questions, not just follow the right steps.

For any organization considering a Power BI investment, that is the bar to aim for. Not just deployment. Empowerment.

Key Takeaways

  1. Power BI security is a three-layer architecture. Workspace roles, row-level security, and sensitivity labels work together to protect data at every level.
  2. Row-level security filters data by user identity. Two people can open the same report and see different data, automatically, based on their role assignments.
  3. Workspace design is a governance decision, not a technical one. IT and business stakeholders need to define the workspace strategy together before deployment.
  4. Content endorsement scales trust. Promotion and certification labels tell users which reports are official and which are works in progress.
  5. Governance and architecture must be designed in parallel. You cannot build the platform first and add governance later.
  6. The best outcome of Power BI training is organizational alignment. When business users ask to meet with IT proactively, the training worked.

FAQ

What is row-level security in Power BI?

Row-level security (RLS) in Power BI restricts which rows of data a user can see when they open a report. It is configured in Power BI Desktop using DAX filter expressions and applied in the Power BI Service by assigning users or security groups to roles. RLS operates at the semantic model level, meaning the filtering happens automatically based on who is logged in. The user sees a normal report experience with only the data they are authorized to access.

How should Power BI workspaces be organized?

Workspaces should be organized intentionally, not organically. Common approaches include organizing by department (HR workspace, Finance workspace), by data domain, or by project. Each workspace should have a designated owner, a clear naming convention, and defined access policies. The workspace strategy should be agreed upon by IT and business stakeholders before Power BI is deployed at scale.

What is content endorsement in Power BI?

Content endorsement is a feature in the Power BI Service that allows workspace owners to mark semantic models and reports as either Promoted (high quality, recommended for use) or Certified (reviewed, meets organizational standards, authoritative). Endorsement helps users distinguish between official reports and works in progress, which is critical in large organizations with many reports across multiple workspaces.

How do sensitivity labels work in Power BI?

Sensitivity labels from Microsoft Purview can be applied to Power BI reports, dashboards, semantic models, and dataflows. Labels like Confidential or Highly Restricted notify users when they are working with sensitive content and apply protections when content is exported to formats like Excel or PowerPoint. The label stays with the content regardless of where it moves, providing persistent data protection beyond the Power BI Service.

What is the difference between workspace roles and row-level security?

Workspace roles control whether a user can access a workspace at all and what they can do there (view, contribute, manage). Row-level security operates inside the workspace, controlling which rows of data a user can see within a report. Both are necessary. Workspace roles are the door. Row-level security is the filter inside the room.

References

  1. Microsoft Learn: Row-Level Security (RLS) with Power BI
  2. Microsoft Learn: Object-Level Security (OLS) with Power BI
  3. Microsoft Learn: Roles in Power BI Workspaces
  4. Microsoft Learn: Endorsement in Fabric and Power BI
  5. Microsoft Learn: Sensitivity Labels in Power BI
  6. Microsoft Learn: Security in Microsoft Fabric

Cory Holmes is an AI Architect, Fractional Chief AI Officer, and Microsoft Certified AI Transformation Leader with 15+ years of experience in enterprise data, cloud infrastructure, and AI. He is currently completing Microsoft Power BI Data Analysis Professional certification and leading a unified data platform initiative built on Microsoft Fabric at a major university. Follow his work at CoryHolmes.com or connect on LinkedIn.

Need help with your data platform or Power BI strategy? Book a strategy call with Fractional AI Advisors.