Most teams build the reports first and govern the model later. That sequencing is why your Finance director has three versions of revenue open in three browser tabs and trusts none of them. The reconciliation meetings that follow are not a data quality problem — they are the direct output of a decision that was never made before the first PBIX file was published.

This post gives you the sequence to run before your next semantic model goes to production, and the prerequisites that separate a certified model from a certified label.

Why the Numbers Never Match

It usually starts cleanly. One analyst publishes a shared dataset from a development workspace, connects a report to it via live connection, and everything works. Then a second team pulls that same published dataset, discovers that “net revenue” excludes a regional adjustment their business unit needs, and duplicates the PBIX file locally to add the measure. They publish to their own workspace. Now there are two dataset artefacts with two different measure definitions, both named “Net Revenue,” both live in the tenant.

A third team finds the second team’s workspace, connects a DirectQuery report to it, and publishes that to a shared dashboard used by senior leadership. When the second team renames a table to match a data warehouse change, the DirectQuery report breaks silently — not with an error, but with a blank visual that people assume is a filter problem. Someone fixes it by duplicating the report and hardcoding the measure. The estate now has four artefacts, zero agreed definitions, and a lineage graph that looks like spaghetti.

When we audit mid-size Power BI tenants — typically 150 to 300 reports — we routinely find 40 or more distinct measure definitions for a single business metric like net revenue or active customers. Each one was created to solve a real problem. None of them were created with permission to become the standard. The failure is not laziness; it is the absence of a single moment where someone said: this definition is final, this model is the source, and nothing downstream changes it without approval.

What a Certified Semantic Model Actually Requires

• A named data owner with write access and accountability. This is a person, not a team. They approve every measure change before it reaches the production workspace. If no individual is named, the certification is decorative.
• A workspace strategy that separates development, UAT, and production as distinct Power BI workspaces — not separate pages or separate reports within the same workspace. Deployment pipelines in Power BI Premium or PPU enforce this; a manual folder structure does not.
• Certified endorsement applied only after a documented review checklist is passed. The checklist must cover measure definitions, relationship integrity, row-level security scope, and refresh reliability. Endorsement applied as a courtesy to a senior stakeholder’s preferred dataset is not certification — it is brand damage to the certification programme.
• A logged change-control process before any measure, relationship, or table is modified in production. At minimum: a written change request, the data owner’s approval, and a record of which downstream reports were tested. A Teams channel with a message is not a change log; a tracked item in your project management tool is.
• Lineage visibility through Power BI’s built-in lineage view and the Scanner API — not a manually maintained spreadsheet. When a measure is renamed, you need to surface every downstream report within seconds, not after a stakeholder complaint. The Scanner API (available via the Admin REST API) gives you programmatic access to the full dependency graph.
• A written extension policy that defines who can build composite models on top of this certified model and under what conditions. Composite models are legitimate and powerful, but an ungoverned composite model can shadow a certified measure with a local one of the same name. The policy must exist before anyone touches the DirectQuery connection.

The Decision Sequence Teams Skip

1. Define the business grain before writing a single DAX measure. Document the lowest level of granularity the model will support — transaction-level, daily aggregate, monthly snapshot — and explicitly state what questions it will not answer. This prevents scope creep that forces relationship changes later. Write it in plain language, get the business owner to sign it, and attach it to the workspace documentation. Power BI’s model description field and table descriptions in the semantic model are the right place to record this, not a separate wiki that goes stale.
2. Lock measure definitions in writing with the business owner, not the BI team alone. Every measure that will be certified needs a definition agreed by the person who owns the underlying business process — Finance owns revenue, HR owns headcount. Use a simple definition table: measure name, business definition, calculation logic, approved by, date approved. This document is the change-control baseline. Without it, every future disagreement is a negotiation rather than a deviation from an agreed standard.
3. Assign workspace roles explicitly using Power BI’s Admin, Member, Contributor, and Viewer model. Do this before the model is shared, not after access requests start arriving. Admin: the data owner and one backup. Member: BI developers who need to publish connected reports. Contributor: analysts who can build in the workspace but cannot publish datasets. Viewer: report consumers. Ad hoc access granted under pressure is how a development-workspace dataset ends up connected to a board-level report.
4. Run a breaking-change simulation before promotion to production. Rename a key table and a core measure in the development environment and observe what breaks across every connected report in that workspace. Power BI’s impact analysis feature, accessible from the dataset settings, shows downstream dependencies. If you discover connected reports you did not know existed, you have a governance gap — fix it before promotion, not after.
5. Set a certified endorsement review cadence — quarterly at minimum — and put it in a calendar now. Certification without a review schedule decays. Data sources change, business definitions evolve, and a model that was accurate in Q1 can be silently wrong by Q3. Each quarterly review should rerun the breaking-change test, reconfirm the data owner is still the right person, and validate that the measure definitions still match the agreed business logic. Use Power BI’s endorsement settings in the workspace to remove certification if a review is overdue — a lapsed-certified model is more dangerous than an uncertified one because people trust it.

Power BI Semantic Models: The Decision Framework Teams Skip

Most teams build the reports first and govern the model later. That sequencing is why your Finance director has three versions of revenue open in three browser tabs and trusts none of them.

The problem is not that Power BI lacks governance features — certification, endorsement, lineage view, workspace promotion controls are all there. The problem is that teams reach for those features after the damage is done: twenty reports live in production, four datasets cover the same grain, and now you are running a reconciliation exercise that should never have started.

This post is about sequencing. Specifically, the three decisions that must happen before the first report is published — and what to do if you are already past that point.

Why Certifying After the Fact Almost Never Works

A certified semantic model is only meaningful if report authors connect to it instead of building their own. By the time most teams apply certification, developers have already published parallel datasets. Those datasets have downstream reports, dashboards, and probably a few scheduled exports that someone in Finance depends on. Certifying one model does not retire the others — it just adds another option to the list.

In one financial services engagement, we found eleven datasets covering the same sales grain across three workspaces. The business had requested a single certified model six months earlier. What they got instead was eleven datasets and a certified badge on one of them. Report authors continued using whichever dataset returned numbers closest to what they expected.

The Three Decisions Before Any Model Goes to Production

These are not process maturity questions. They are decisions you can make this week, and without them no certification label will hold.

• Who owns this model? Not a team — a named individual with authority to approve or reject changes to measures, relationships, and schema. If ownership is collective, it is nobody’s.
• What breaks if it changes? Before promotion, map every known downstream consumer: reports, Power Automate flows, Excel connections, embedded analytics. This is your impact register. A change to a measure name or DAX logic will silently break any report that references it by name.
• Who is allowed to extend it? Composite models and live connections let developers build on a certified model without touching it — but without a declared policy, those extensions become ungoverned shadow models within weeks.

None of these require a steering committee or a governance programme. They require a decision, a name against it, and somewhere to write it down.

Composite Models: Where Governance Breaks Down Fast

Composite models are where well-governed semantic models quietly unravel. The pattern is consistent: a developer connects to a certified model in DirectQuery mode, adds a few local import tables — typically a cost centre hierarchy or a regional mapping file — and publishes the result to a workspace. From the outside, it looks like an extension of the certified model. It is not. It is a separate PBIX with no lineage tracked back to the original, no change-control history, and no declared owner.

The failure mode surfaces when the upstream certified model changes a measure — say, the revenue calculation is updated to exclude intercompany transactions. The certified model returns the correct number. The composite model, depending on how the measure was referenced, either returns the old calculation silently or breaks without a clear error message. Report consumers see different totals from what they believe are the same source. They are not wrong to be confused.

The governance rule that prevents this is specific: any composite model built on a certified semantic model must be declared, stored in a workspace that sits within the same governance boundary as the parent, and included in the parent model’s change-control review. This is not optional process overhead — it is the only way to know what breaks before you publish an upstream change.

Power BI surfaces this risk through model lineage in the Admin portal and the Fabric Scanner API. Run the Scanner API against your tenant and look for datasets that reference a certified model as a source — those are your undeclared composites. Find them before they find you.

The Governance Decisions in Order

Starting Point for Teams Already in Reconciliation Hell

1. Run a lineage audit now. Use Power BI’s built-in lineage view and the Admin REST API (GET /v1.0/myorg/admin/reports with dataset mapping) to export every report-to-dataset relationship as a flat list. A diagram is too slow to act on — a spreadsheet is faster to sort, filter, and assign.
2. Find your de facto semantic models. Sort the flat list by downstream report count. The two or three datasets with the highest count are already acting as shared models, certified or not. Governance starts there, not with a greenfield build.
3. Freeze those datasets immediately. No schema changes, no new measures, no DAX edits without written approval from a named owner. Apply the Endorsed endorsement as a temporary marker — it signals intent to report authors while you complete the certification checklist. This can be done in under an hour.
4. Set a hard deprecation date for duplicates. Identify every dataset covering the same grain as your de facto models and communicate a specific date — four to six weeks is achievable — after which those datasets will be removed from production workspaces. Soft deprecation warnings without dates are ignored.

Frequently asked questions

What is the difference between an endorsed and a certified semantic model in Power BI, and which should we use?

Endorsed is self-service — any workspace admin can apply it, and it signals that a dataset is recommended within a team or domain. Certified requires a Power BI admin and is intended to signal tenant-wide trustworthiness. Use Endorsed as a staging marker while you build the certification checklist. Use Certified only once ownership, the measure register, and the impact register are complete. Applying Certified too early teaches report authors to ignore the badge.

How do we stop developers from duplicating shared datasets instead of connecting to the certified model?

Two controls work together. First, publish the certified model in a workspace where developers have Viewer or Build access — Build permission lets them create reports connected to the model without being able to edit it. Second, set a workspace policy that bars promotion of any new dataset that covers the same grain as an existing certified model without a written exemption from the model owner. Policy without access control is advisory. Access control without policy leaves the reason implicit — you need both.

Can we have multiple certified semantic models for different subject areas, or does certification require a single enterprise model?

Multiple certified models by subject area — Finance, HR, Supply Chain — is the correct architecture for most mid-to-large organisations. A single enterprise model becomes a bottleneck and a political liability. The constraint is cross-domain consistency: shared dimensions like date, entity, and cost centre must resolve to the same definition across models. Document those shared definitions centrally and enforce them at certification review. The models can be separate; the definitions cannot.

What happens to downstream reports when we change a measure in a certified semantic model?

If you rename a measure, any report that references it by name will break at refresh or fail to load the visual. If you change the DAX logic without renaming, reports continue to load but return different numbers — which is worse, because the error is invisible. Before any measure change, run the impact register to identify every downstream report, notify owners, and test in the Dev workspace using a deployment pipeline before promoting to production. Power BI deployment pipelines support comparison views that surface changed objects — use them.

How does Power BI semantic model governance work in Microsoft Fabric — does the approach change?

As of 2025, Microsoft Fabric introduces OneLake as the unified storage layer and Direct Lake mode as a third connection type alongside Import and DirectQuery. Direct Lake reads