The Short Answer

Master Data Management isn't a database; it’s an agreement. This agreement defines who establishes an entity, who is authorized to modify it, how two records are identified as the same entity, and what happens when systems disagree. Technology merely enforces what has been agreed upon.

The common pitfall is starting by selecting a tool. An organization that hasn't clarified what defines a "customer" will end up with a tool that consolidates the exact same ambiguity, just faster and at a higher cost.

What Belongs in Master Data and What Doesn't

Data TypeExampleIs it Master Data?
Master DataCustomer, Product, Vendor, SiteYes
Reference DataCountries, Currencies, Industry CodesSeparate, simpler management
TransactionalOrder, Invoice, CaseNo
AnalyticalSegmentation, Scoring, ForecastNo - Derived

This distinction is crucial because each type requires a different governance approach. Reference Data is managed in a small table with a single owner; Transactional Data remains in its originating system; Analytical Data must not become a source of truth, as it's a product of changing calculations.

Three Implementation Styles

Registry - Manages only an identifier table that links records across different systems. It’s inexpensive, fast, doesn’t alter any existing systems, and provides a unified view for reading. This is almost always suitable as a first step.

Consolidation - Creates a Golden Record for reporting and analysis purposes, without flowing it back to source systems. Suitable when the primary pain point is fragmented reporting.

Centralized - The Master Data becomes the authoritative source, and all systems consume from it. This offers the highest value but also demands the highest level of governance and approval processes. Organizations that jump straight to this often discover they lack the Stewards to operate it effectively.

The practical approach is a ladder: start with a Registry for one entity, then expand – based on proven value rather than a master plan.

Survivorship: The Rules That Determine What Survives

The core of the Golden Record lies in field-level Survivorship rules: each field has a preferred source and a backup rule for when the preferred source is empty. Alongside this, source system identifiers are always retained, allowing every value to be explained.

A principle that avoids arguments: A Golden Record neither deletes source records nor claims to replace them. It's a layer that points to them. This means you can correct a rule and recalculate – a capability unavailable to those who merge everything at the loading stage.

Further depth on ownership determination can be found in Source of Truth in an Organization and the preceding deduplication process in Salesforce Data Deduplication.

Stewardship: The Role That Determines Success

Any MDM governance model generates a decision queue: matches the system is unsure about, requests to create new entities, and contradictions between sources. If there's no person with dedicated time to clear this queue, it grows until it's ignored.

A realistic scope: In a mid-sized organization, this means a few dedicated hours per week for one entity, often allocated to someone from the business side rather than IT. This investment determines whether MDM truly thrives or becomes silent infrastructure.

Scenario: Manufacturer with Three Systems and One Customer

An industrial manufacturer managed customers in three places: ERP, Salesforce, and a service system. The same corporation appeared as three distinct entities, and a "revenue per customer" report was manually built in Excel quarterly.

Instead of a full MDM project, the organization began with a Registry: an identifier table was built in Data 360, linking the three records using a tax ID and a secondary key, and only then was a read-only Golden Record constructed. Salesforce didn't change its structure; it received a global identifier field and a "all activity for this group" view.

The outcome after a quarter: The manual report was eliminated, and for the first time, sales representatives saw credit exposure at a group level – which prompted a single pricing decision that recouped the cost of the phase. Expansion to a Centralized model was considered only after it was proven that a Steward was actively clearing the queue.

Common Risks and Preventive Actions

RiskHow It Manifests in PracticePreventive Action
Starting with a toolA unified repository reflecting existing ambiguityDefine entity and ownership before tool selection
Too many entitiesA long project with no visible valueOne entity to production, then expand
No StewardA matching queue that grows and is abandonedAppoint a role with dedicated time and an SLA
Destructive mergingUnable to explain or restore a valueRetain source identifiers and allow recalculation
Premature CentralizedAll systems dependent on immature infrastructureStart with a Registry

How to Measure Success

AreaWhat to MeasureCheck Frequency
CoveragePercentage of records linked to a global identifierMonthly
AccuracyRate of links revoked or correctedMonthly
Stewardship QueueOpen items and average closing timeWeekly
Business ValueManual reports eliminated, group-level decisions enabledQuarterly

Building a tiered MDM framework is performed within Integrations and Data Services.

MDM Pre-Initiation Checklist

  • ☐ Up to three entities selected for the first wave
  • ☐ A written business definition exists for each entity
  • ☐ Implementation style chosen: Registry, Consolidation, or Centralized
  • ☐ Strong identification keys located for each source
  • ☐ Survivorship rules written at the field level
  • ☐ Source identifiers retained, allowing recalculation
  • ☐ A Steward designated with dedicated time and an SLA
  • ☐ An approval process defined for new entity creation
  • ☐ One value metric determined for the first wave
  • ☐ A decision made on when to even consider a dedicated tool

Professional Resources