The Four Ways to Master Data
Also in 28 languages
Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 2 of 6 in the chapter Master Data and Identity, chapter 6 of the Data Architect course. Each module stands on its own. Previous: One Source of Truth per Attribute · Next: Matching, Merging and Survivorship
The question this module answers: How do organizations master data, and which style fits?
Module 1 said authority is assigned attribute by attribute. Now: what do we do when those attributes live in several systems at once? Customer information in Salesforce, the ERP, billing, support, maybe Data 360, maybe a warehouse, each with its own version. That’s the problem master data management (MDM) tries to solve, and MDM isn’t one architecture. You’ll hear four patterns: registry, consolidation, coexistence and centralized. They aren’t product settings. They’re four answers to one question: how much authority does the mastering layer have?
Start With the Problem, Not the Product
Section titled “Start With the Problem, Not the Product”People hear MDM and start shopping for an MDM product. I’d start with the problem. Do we just need to know that several records are the same customer? Do we need one combined view for analytics? Do we need to decide which values are authoritative and push them back to other systems? Or do we want one central system creating the master data for everyone? Very different requirements, very different architectures.
Registry: Tell Me Who Is Who
Section titled “Registry: Tell Me Who Is Who”The lightest pattern. A registry doesn’t replace the sources. The ERP keeps its customer, Salesforce its account, billing its customer, and the registry works out that these records represent the same entity: Salesforce account 001…, ERP customer SAP-43821 and billing customer BILL-9127 belong to one customer. The sources stay where they are and aren’t overwritten. Now “show me everything we know about this customer” has an answer.
But notice what a registry doesn’t answer. Salesforce says 123 Main Street, the ERP 125, billing “123 Main St., Suite 200.” The registry knows they belong together. It doesn’t decide which one should change. Linking isn’t mastering.
In my experience, registry is the norm on Salesforce projects, then consolidation and coexistence; pure centralized MDM is rare. Registry is common because it’s non-invasive. You don’t redesign every operational system before getting value. Salesforce keeps doing what it does, the ERP keeps doing what it does, and you add an identity layer. That’s a far smaller change than telling every system “you no longer control customer data; this new central system does.”
Registry answers: which records belong to the same entity?
Consolidation: Bring the Data Together
Section titled “Consolidation: Bring the Data Together”Consolidation takes data from several sources and combines it into a central representation, for reporting, analytics, segmentation, customer intelligence. A warehouse is the familiar example: Salesforce sends the customer, the ERP the financials, billing the payments, and the business can finally analyze the customer across systems. The sources still exist and may still be authoritative. The direction matters: data flows into the consolidated system, which usually doesn’t push mastered changes back. A better picture of the customer, without becoming its operational authority.
Registry and consolidation are easy to confuse. The difference is what’s centralized: registry centralizes identity (“these belong together”); consolidation centralizes more of the data (“bring the attributes together so we can use them”). Neither says “this central system is now the master and every application must accept its values.”
Consolidation brings the data together without taking ownership away from the sources.
Coexistence: Decide, and Send It Back
Section titled “Coexistence: Decide, and Send It Back”In coexistence, the mastering layer gets real authority. Data still lives in several operational systems, but the MDM process decides the mastered value and publishes it back. Salesforce, the ERP and billing each have a different legal name; the MDM process determines the governed one and distributes it to all three. The systems coexist, but they converge on the mastered value.
That’s a much stronger form of MDM. It isn’t saying “these belong together”; it’s saying “for this attribute, this is the value the enterprise uses.” That takes more than matching: business rules, ownership, survivorship, two-way integration, error handling and governance, because somebody has to decide why one value wins.
Coexistence doesn’t just link the records. It decides mastered values and sends them back.
Centralized: the Master Creates the Truth
Section titled “Centralized: the Master Creates the Truth”The strongest pattern. In centralized MDM, the governed master data is created and maintained in the central master and distributed to everyone else. Instead of each system creating its own customer and MDM reconciling them afterward, you create the governed customer in the master, then send it to Salesforce, the ERP and billing. Very strong governance, and very significant change: existing processes create their own customers, users have their workflows, integrations assume local creation, and business units may not even agree on what a customer is. That’s why it’s rare in the Salesforce landscapes I see. It can be right. It’s a much bigger decision than installing a tool.
Centralized MDM moves creation and authority into the master.
The Four Side by Side
Section titled “The Four Side by Side”| Style | What’s centralized | Do sources remain? | Pushes governed values back? |
|---|---|---|---|
| Registry | Identity and links | Yes | Usually no |
| Consolidation | Identity plus combined data | Yes | Usually no |
| Coexistence | Identity, data and mastered decisions | Yes | Yes |
| Centralized | Creation and authority | Yes, as consumers | Yes |
Down the table, the mastering layer gets more authority, and the organization usually has to change more.
Test knowledge. Know the four MDM implementation styles: registry (links identities; the sources keep their data), consolidation (brings the data together, usually for analysis), coexistence (decides mastered values and publishes them back to the sources) and centralized (the master creates the data; the sources consume it).
So there’s no “centralized is most mature, so everyone should get there.” Choose the lightest pattern that solves the problem. Need to know records belong together? Think registry. A combined view for analytics? Consolidation. Governed values synchronized back to several operational systems? Coexistence. One process creating and controlling master data for everyone? Centralized.
Where Does Data 360 Fit?
Section titled “Where Does Data 360 Fit?”Data 360 builds unified profiles across many sources, which sounds a lot like MDM, and it does solve part of the problem. Its identity resolution matches source profiles into a unified identity and keeps the links back to the source records (Data 360 Architecture (opens in a new tab)). That makes it closest to a registry. It can also show reconciled values on the unified profile. But that doesn’t make it a centralized golden-record system that rewrites the sources. A unified view isn’t automatically a mastered enterprise record. Module 4 is all about that difference.
A Common Model Isn’t a Common Truth
Section titled “A Common Model Isn’t a Common Truth”You’ll also hear canonical data model. Salesforce’s Account, the ERP’s business partner and billing’s customer all map to one agreed enterprise concept, Customer, with agreed identifiers and attributes, so every integration doesn’t have to understand every other system’s shape. Data 360’s data model is an example of harmonizing sources into common concepts. But a canonical model answers how do we represent this consistently? MDM answers how do we identify, govern and master it across systems? Map all three systems perfectly into one Customer shape, and Salesforce still says 123 Main Street while the ERP says 125. You’ve solved the structure, not the authority. Harmonizing and mastering aren’t interchangeable.
One Business, Several Patterns
Section titled “One Business, Several Patterns”So “Steve Trucking needs MDM” isn’t a requirement. For what? Retail Partners, distribution centers, crews, trucks, Recipients are different domains with different authorities: Retail Partners governed in Salesforce and the finance ERP, truck identity from FleetLink, each Recipient supplied by a partner for each delivery. Different domains can take different patterns, and within a domain, attributes can have different authorities. So don’t draw a box labeled MDM in the middle of the diagram and call it solved. Ask what the box does.
The style also changes the integration. Registry needs identity links; consolidation, reliable inbound flows; coexistence, data in both directions; centralized, distribution from the master plus controls that stop other systems creating rival truth. As authority grows, so does coordination, and so does failure handling: what if MDM changes the legal name and the ERP rejects it? That’s why coexistence and centralized aren’t “registry with more features.” They carry different operational responsibilities.
MDM Is a Business Decision
Section titled “MDM Is a Business Decision”The most important point: MDM isn’t fundamentally a technology decision. It’s a decision about authority. Who creates the customer, who may change it, who decides which value wins, which systems must accept it, what happens when they disagree. A tool can implement those decisions; it can’t make the organization agree on them. That’s why an MDM project can have excellent technology and still fail: the technical team solved matching, and the business never solved ownership.
The general lesson I’ve learned the hard way: when several systems master the same data, Salesforce can’t reconcile what they don’t agree on. When a company runs two ERPs, I ask how they keep them in sync. If they can’t, Salesforce can’t either. Module 5 tells that story (One Customer, Two ERPs).
What an Architect Decides Here
Section titled “What an Architect Decides Here”- Whether the problem needs identity links, combined data, mastered values pushed back, or central creation.
- Which pattern fits each data domain, rather than one pattern for the whole enterprise.
- How much authority the mastering layer gets, and which systems must accept its decisions.
- Whether a canonical model is needed, without confusing harmonization with authority.
- How the chosen pattern changes integration direction, ownership and failure handling.
When someone puts an MDM box on a diagram, ask what it does. Does it know which records belong together? Combine their data? Decide which values win? Push those decisions back? Create the data in the first place? The answers tell you which architecture you really have, and where the authority lives.
Explore
Section titled “Explore”- Salesforce Architects, Data 360 Architecture (opens in a new tab), checked 2026-10-14.