Data Analytics

Power BI Governance: What I Learned About Security, DAX, and Semantic Models

Lessons from Day my Microsoft Power BI training on data governance, DAX calculated measures vs columns, semantic models, row-level security, and why design standards matter.

Day 1 of this Microsoft Power BI Data Analysis Professional course was about the foundation: connecting to data, cleaning it, and shaping it into something reliable. I wrote about that experience here.

Day 2 was about building on that foundation. We moved into visualization, data modeling, and the mechanics of turning structured data into meaningful reports.

But the most important moment of the day was not in the curriculum. It was a question from a business stakeholder that the instructor could not fully answer.

Why Power BI Design Standards Are a Governance Decision

The first thing the instructor emphasized before we built a single visualization: establish a design standard and stick to it.

Every report your organization publishes should follow consistent guidelines:

The same logo placement
The same color palette
The same font choices
The same layout conventions

Not because visual consistency is a nice-to-have, but because it signals something important to everyone who reads those reports: this is official. This is trusted. This came from a governed process.

Think about what happens in organizations without a design standard. Power BI gets rolled out, departments start building their own reports, and within a few months leadership is looking at a dozen different styles. Some use the company logo, some do not. Colors vary. Metric names differ. And because nothing looks authoritative, nothing feels authoritative. The tool that was supposed to create clarity has created a new layer of confusion.

A design standard is not an aesthetic preference. It is how an organization communicates to its people which reports to trust and which ones are works in progress.

For organizations rolling out Power BI across multiple departments, establishing that standard before reports get published is far easier than trying to enforce it after.

In the context of the unified data platform we are building at a major university, this point landed with real weight. We have six departments that have historically built their own reports in their own way. Consolidating onto Power BI is not just a technology migration. It is an opportunity to establish a consistent visual language across the entire institution, so that a report from HR and a report from Finance feel like they came from the same organization. Because they should.

Calculated Measure vs. Calculated Column: Why It Matters for Your Semantic Model

Day 2 went deep into DAX, which is the formula language Power BI uses to create calculations. For practitioners, understanding DAX is what separates someone who can use Power BI from someone who can architect a semantic model that scales.

Two concepts from today are worth understanding at every level of the organization, not just the technical level.

Calculated Columns

A calculated column extends a specific table in your data model. It adds a new column, row by row, based on a formula you define. It is table-specific, stored in memory, and evaluated when the data model is loaded or refreshed.

If you need to categorize records or create a new field based on existing data in a single table, a calculated column is the right tool.

Calculated Measures

A calculated measure works differently. It does not live in a specific table. It lives in the semantic model itself and can be used across any report, any visualization, and any context. It is evaluated on the fly, only when it is needed, and it always reflects the current state of the data.

If you need to define a business metric that is used consistently across your entire reporting environment, a calculated measure is the right tool.

Why Executives Should Care About This Distinction

Calculated measures are how organizations define what things mean. What counts as revenue. How enrollment is calculated. What the official definition of an active customer is.

When those definitions live in the semantic model as calculated measures, they are consistent everywhere. Every report that uses that measure gets the same answer. The problem of two reports showing different numbers for the same metric goes away, because the metric is defined once and applied everywhere.

This is the technical foundation behind the semantic modeling concept I covered in depth earlier. The semantic model is not just a data layer. It is where your organization encodes its business logic. Getting it right is one of the most important investments a data initiative can make.

Power BI Row-Level Security: The Question Nobody Could Fully Answer

Late in the day, a business stakeholder asked a question that stopped the room.

When we publish a report from a semantic model that contains calculated measures, how do we make sure that the people who should not see certain data cannot see it? How do we ensure that sensitive information, say HR compensation data or individual student records, does not show up in a report that was meant for a broader audience?

It is exactly the right question. And I don't think the instructor had a confident answer to give.

Power BI does have security mechanisms:

Row-level security (RLS) allows organizations to control which rows of data a user can see based on their identity
Object-level security (OLS) can restrict access to specific tables or columns
Workspace permissions control who can publish, edit, or view reports

These tools exist and they work. But the honest answer is that data security in a Power BI environment is not a feature you turn on. It is an architecture you design. And that architecture has to be planned before reports are published, not after.

The decisions made at the semantic model level, at the data source level, and at the workspace level all contribute to what any given user can and cannot see when they open a report.

For organizations managing sensitive data, whether that is financial information, personnel records, student data, or research findings, this is not a Power BI question. It is a data governance question. Power BI is one layer of the answer. The rest of the answer lives upstream, in how your data platform is structured, who owns each data domain, and what access controls are in place at every layer of the pipeline.

In a medallion architecture, governance controls should be applied before data ever reaches the semantic model. That way, Power BI's security features become an added layer of protection, not the only one.

The fact that this question came up in a room full of business users and did not get a clean answer is itself useful information. It means that as your organization moves toward self-service analytics, the governance conversation needs to happen in parallel, not after the fact. The people building reports and the people responsible for data governance need to be in the room together before the first report goes live.

What Day 2 of Power BI Training Revealed

Beyond the specific lessons, what Day 2 made clear is that Power BI is not just a reporting tool. It is a system that reflects the maturity of your organization's data practices.

A well-designed report built on a governed semantic model with clear security controls is evidence of an organization that takes its data seriously. A patchwork of inconsistent reports built on top of uncontrolled data is evidence of one that does not.

The tool does not determine which outcome you get. The decisions made before anyone opens Power BI do.

Next, we move into advanced analysis, sharing, and managing the Power BI Service at scale. That is where the governance questions get even more interesting.

Key Takeaways

Design standards are governance decisions. Consistent report branding signals trust and authority across the organization.
Calculated measures define what metrics mean. They live in the semantic model and ensure every report uses the same business logic.
Calculated columns extend individual tables. Use them for row-level categorization, not for shared business metrics.
Row-level security is necessary but not sufficient. Data security in Power BI requires architecture decisions at the semantic model, data source, and workspace levels.
Governance conversations must happen before reports go live. Retrofitting security and standards is harder and riskier than designing them upfront.
Power BI reflects your data maturity. The tool does not determine the quality of your reports. Your data foundation does.

FAQ

What is Power BI row-level security?

Row-level security (RLS) in Power BI restricts which rows of data a user can see when they view a report. It is defined using DAX filters in the semantic model and applied based on user identity. For example, a regional sales manager might only see data for their region, while a VP sees all regions. RLS is one of several security layers available in Power BI, alongside object-level security and workspace permissions.

What is the difference between a calculated column and a calculated measure in Power BI?

A calculated column adds a new column to a specific table, evaluated row by row when the data model loads. A calculated measure is a DAX formula that lives in the semantic model and is evaluated on the fly at query time. Calculated columns are best for row-level categorization within a single table. Calculated measures are best for business metrics (like revenue or enrollment counts) that need to be consistent across all reports.

Why does Power BI governance matter?

Without governance, self-service analytics creates inconsistency. Different departments define metrics differently, reports have inconsistent branding, and sensitive data may be exposed to the wrong audiences. Power BI governance includes design standards, semantic model management, row-level security, workspace permissions, and data quality controls. It ensures that reports are trusted, consistent, and secure across the organization.

How does a semantic model support Power BI governance?

A semantic model is where business logic is defined in Power BI: metric calculations, relationships between tables, hierarchies, and security rules. When all reports connect to the same governed semantic model, they use the same definitions. This eliminates the problem of two reports showing different numbers for the same metric. The semantic model is the single source of truth for business intelligence.

References

Cory Holmes is an AI & Data 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.