Master Data Management

Master Data Management (MDM) is the set of processes and tools that create one trusted “golden record” for core business entities referenced across many systems.

At a glance

• What it is: Matching, merging, and governance processes that reconcile multiple systems’ versions of the same entity (customer, product, supplier) into a single authoritative record.
• Why it matters: Without MDM, “how many customers do we have?” doesn’t have one answer — it has one answer per system, and none of them agree.
• For developers: before wiring a new integration that creates records for people, products, or organizations, ask whether it should create a new record or link to an existing master record — skipping this is how duplicate-customer bugs are born.
• When to use it: When the same real-world entity is created, updated, or referenced independently across multiple systems.
• When not to use it: For entities that only ever exist in one system — there’s no duplication risk to reconcile.
• Prerequisites: Data Modeling & Schema Design.

Mental model

graph LR
    CRM["CRM: Bob Smith"] --> MDM["MDM matching & merging"]
    Support["Support: Robert Smith"] --> MDM
    Billing["Billing: 2 duplicate records"] --> MDM
    MDM --> Golden["Golden record: one Customer"]
    Golden --> CRM2["Published back to CRM"]
    Golden --> Support2["Published back to Support"]
    Golden --> Billing2["Published back to Billing"]

MDM doesn’t replace the source systems — it sits alongside them, reconciling their records into one trusted version and publishing that version back so every system can reference the same identity.

Step-by-step walkthrough

1. Identify which entity needs mastering (customer, product, supplier) and every system that holds a version of it.
2. Discover and profile each source system’s records for that entity.
3. Define matching rules to detect when records from different sources represent the same real-world entity.
4. Define survivorship rules to decide which source’s value wins when sources disagree on an attribute.
5. Store the resulting golden record and distribute it back to consuming systems via IDs or synchronization.

Worked example

Northwind has three versions of the same person: CRM lists “Bob Smith”, Support lists “Robert Smith”, and Billing has two duplicate entries for him with mismatched addresses.

• Input: four records across three systems, no shared identifier, inconsistent names and emails.
• Process: matching rules use fuzzy name matching plus shared phone number and address to link all four records as the same person; survivorship rules say the most recently verified email wins, and the most recent address from a verified shipment wins.
• Output: one golden Customer record with a canonical ID, published back to CRM, Support, and Billing so all three now reference the same identity instead of four disconnected records.

public sealed record GoldenCustomer(Guid GoldenId, string Name, string Email, string SourceSystem, DateTimeOffset VerifiedAt);

GoldenCustomer ApplySurvivorship(IEnumerable<GoldenCustomer> candidates) =>
    candidates.OrderByDescending(c => c.VerifiedAt).First(); // most recently verified value wins

The golden record is published back to CRM, Support, and Billing as a CustomerMastered event on Azure Service Bus, so each system updates its local reference without polling the MDM store directly.

Common use cases

Use case	When to use	Notes
Customer 360	Building a unified view of a customer across sales, support, and billing	The most common entry point for MDM initiatives
Product master	E-commerce, catalog, and supply chain systems each hold product data	Prevents conflicting product descriptions/pricing across channels
Supplier master	Procurement, finance, and compliance track supplier records separately	Reduces duplicate payments and compliance risk

Advanced details

• Matching approaches: deterministic matching (exact key match) is simple but misses variants; probabilistic/fuzzy matching catches more duplicates but needs tuning and human review for low-confidence matches.
• MDM styles: registry style keeps golden IDs as a cross-reference without moving data; hub style centralizes the actual golden record; hybrid approaches combine both depending on the entity.
• Stewardship workflow: automated matching should route low-confidence matches to a human steward rather than auto-merging — silent incorrect merges are worse than unresolved duplicates.
• Golden record storage: the golden record doesn’t have to live in a relational table — because source systems attach different extra attributes to the same entity, a flexible-schema store like Azure Cosmos DB (one document per golden entity) is often a better physical fit than forcing every source system’s extension attributes into a single wide relational table.

Quick reference

Term	Meaning
Golden record	The single trusted, authoritative version of an entity
Match/merge	The process of detecting and combining records that represent the same entity
Survivorship rule	The rule that decides which source’s value wins when sources disagree
Registry style	MDM that cross-references golden IDs without centralizing the data itself
Hub style	MDM that centralizes and stores the golden record directly

Troubleshooting

Symptom	Likely cause	Fix
Duplicate customers keep appearing	Matching rules too strict (exact match only)	Introduce fuzzy/probabilistic matching with a confidence threshold
Wrong value wins after a merge	Survivorship rules undefined or too simplistic	Define explicit per-attribute survivorship rules, not “last write wins” everywhere
Downstream systems still show old data	Golden record isn’t being distributed back to consumers	Add a publish/sync step so consuming systems receive golden-record updates

Check your understanding

• Why can silently auto-merging two low-confidence matches be worse than leaving them as duplicates?
• Pick an entity your team manages that exists in more than one system — is there a shared identifier between the two today, or would you have to guess?

Related pages

Part of Introduction to Data Architecture. See also Data Modeling & Schema Design for the canonical entity models MDM reconciles against, Data Governance & Stewardship for who owns those decisions, and the Glossary for term definitions.