If your CRM, finance system, and partner records each hold a slightly different version of the same customer, supplier, or institution, you don't have a data problem — you have a trust problem. Master Data Management (MDM) is the discipline that fixes this: it reconciles every source system's version of a core entity into one governed, trusted record, and makes that record available consistently across every report your organisation relies on. On Microsoft Fabric, this isn't a separate product you bolt on — it's a pattern you build into your data platform from day one.

This article is written for CDOs, Data Directors, Analytics Managers, and IT leaders overseeing a Fabric migration or modernisation programme. You'll learn why fragmented master data quietly undermines every KPI your board sees, what a golden record actually is, and how the pieces fit together across OneLake, Lakehouse, Warehouse, and Power BI.

The business cost of fragmented master data

Every organisation running more than two or three systems ends up with the same problem: the same customer, supplier, or institution recorded slightly differently everywhere it appears. A CRM might hold "Contoso Manufacturing," finance might hold "CONTOSO MFG," and a partner portal might hold "Contoso Mfg, Seattle WA." Each is obviously the same entity to a person reading them — but to a data warehouse or a Power BI semantic model, they're three unrelated rows with three unrelated keys.

The downstream cost isn't abstract. It shows up as split revenue or enrolment figures that don't reconcile, broken joins between fact and dimension tables, an inability to answer "show me everything about this customer" with any confidence, and slower, more painful regulatory and audit processes. Every BI team that hasn't solved this centrally ends up reinventing its own ad-hoc matching logic — inconsistently, and usually under deadline pressure.

What Master Data Management actually solves

MDM draws a clear line between four types of data that are often lumped together. Master data covers your core entities — Customer, Product, Supplier, Employee, Store/Location, Organisation. Transactional data records what happened — an order, an invoice, an attendance record — and always points back to master data. Reference data is small and stable, like country or currency codes. Metadata describes the data itself — its lineage, its owner, its sensitivity classification.

MDM's job is to govern the first category — master data — because everything else in your reporting estate depends on it being right. Get the Customer or Product dimension wrong, and every fact table built on top of it inherits that error at scale.

The golden record: one trusted version of the truth

A golden record is the single, agreed representation of one real-world entity, built through a repeatable process: standardise every source record's formatting, match records that likely represent the same entity, cluster the matches, apply survivorship rules to decide which source's value wins for each attribute, and publish the result with a permanent master ID.

Crucially, not every match is certain. A strong match on a unique identifier — a federal Employer Identification Number (EIN), a D-U-N-S Number, or a store/location code — can merge automatically. A fuzzy match on name and address alone should route to a human steward for review before anything is merged. This human-in-the-loop step is what separates real MDM from a one-off deduplication script that quietly gets things wrong.

Where MDM fits in Microsoft Fabric

Fabric doesn't ship a packaged, dedicated MDM product — instead, MDM is implemented as a governed pattern across Fabric's existing components, and that's a strength: your master data logic lives in the same open, Delta-based platform as the rest of your estate rather than in a separate silo.

Fabric Data Factory (or Azure Data Factory) orchestrates extraction from every source system on schedule. Raw extracts land in OneLake's Bronze layer inside a Lakehouse, get standardised and validated into Silver, and the matching and survivorship logic — typically built in Notebooks — produces the golden records and crosswalk table in Gold. A Fabric Warehouse then exposes those golden dimensions as a proper star schema, and your Power BI semantic model consumes it via Import or DirectLake, giving report authors one clean Customer or Product table instead of several conflicting ones.

The result is a platform where matching logic is centralised once, in one governed place, rather than duplicated silently across a dozen report workbooks.

Governance and ownership: making MDM sustainable

MDM only stays trustworthy if someone is accountable for it. A Data Owner — usually a senior business stakeholder — is accountable for what "correct" means for a domain and approves the survivorship rules. A Data Steward handles the day-to-day: reviewing ambiguous matches, correcting golden-record values, and monitoring data-quality dashboards. Your Data Engineer builds and runs the pipelines that implement all of this, and your BI Developer ensures every report joins through the master ID rather than a raw source-system key — the single rule that prevents most "duplicate customer" bugs from creeping back in.

This governance layer also has to account for change over time. When an institution renames itself, or a supplier is acquired, the master ID stays the same — the golden record is versioned, not replaced — so historical reports still show the entity correctly as it was at the time, while current reports reflect its present identity. Read more about building this discipline into your programme through our data governance consulting services.

What changes when you get MDM right

The difference between an organisation with mature MDM and one without shows up directly in how confidently leaders can trust their reporting.

Next steps for your data strategy

If your Fabric migration is underway and master data hasn't been addressed explicitly, it's worth resolving before your Warehouse and Power BI semantic models are finalised — retrofitting a golden-record layer onto an existing model is considerably more disruptive than building it in from the start. Our Microsoft Fabric migration team builds this pattern into every platform we design, alongside the Power BI consulting work that turns golden records into a single, trustworthy customer or product view for your leadership team.