Master Data and Identity
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)
Chapter 6 of Data Architect, Part 1: Becoming a Data Architect. Previous: Data Quality and Governance.
“We need a single source of truth.” It’s one of the most repeated phrases in architecture, and one of the least examined. For what? Take one account. The ERP may own its legal name, billing address and credit limit; Salesforce its account executive and support tier; a consent platform its marketing preferences. Three authorities on one record, and that’s normal. So when someone says “Salesforce is our single source of truth for the customer,” my next question is always: which truth?
This chapter is about answering that question on purpose. Authority is assigned attribute by attribute. Linking records isn’t mastering them. And Salesforce gives you different tools for different jobs: duplicate management and merge inside one org; Data 360 identity resolution for one view across sources; a dedicated MDM platform when values must be decided once and pushed back everywhere. It ends with Checkpoint 1, where Part 1 comes together on Steve Trucking.
Image generated with AI.
The positions in this chapter
Section titled “The positions in this chapter”- Truth per attribute. Ask where each piece of data is created, edited and referenced, and how fast it changes. Show external authority in the schema with a system prefix, such as
sap_orerp_. - Prospects are different. They live in Salesforce before the ERP knows them; ERP authority applies after conversion.
- Registry is the norm on Salesforce projects, then consolidation and coexistence; pure centralized MDM is rare.
- Merge only with a clear winner. Keep duplicates from external loads when you may need to trace back; merging destroys that history. And decide what happens to the children: move them, don’t load them, or keep them on an inactive record.
- A unified profile is a map; a golden record is a decision. This can be confusing for people: identity resolution creates a unified individual, but not a golden record.
- Match strictness is a risk decision. Where blending is costly, under-match on purpose.
- Three tools for three jobs: merge, identity resolution, MDM.
- Hierarchies are split-mastered. Decide authority branch by branch.
- “The hardest thing are the bi-directionals.” A two-way integration doesn’t make two masters. Decide which fields travel together as one transaction before the first collision.
- Make master data visible. A field that says this is master data (the ERP’s key or a flag) drives editability, not a record type.
- We don’t control the ERPs. We control how we represent them in Salesforce: one customer in two ERPs is a hierarchy, peers, or one account with a child per ERP, decided by how well the client keeps its ERPs in sync.
Three tools for three jobs
Section titled “Three tools for three jobs”| The job | The tool | What it does to the sources |
|---|---|---|
| Duplicates inside one org, with a clear winner | Duplicate management and merge | Merges up to three records; the others go to the Recycle Bin |
| One identity and a single view across sources | Data 360 identity resolution | Links them; changes none of them (a registry) |
| One governed value, pushed back to every system | A dedicated MDM platform | Decides the value and distributes it (coexistence or centralized) |
The path through this chapter
Section titled “The path through this chapter”Six modules and a challenge, each standing on its own.
- One Source of Truth per Attribute. The authority map, the hybrid golden record, and trust signals.
- The Four Ways to Master Data. Registry, consolidation, coexistence and centralized, and why a common model isn’t a common truth.
- Matching, Merging and Survivorship. The cost of a false match, what a Salesforce merge really does (and what happens to the children), and survivorship as a statement about trust.
- A Map Is Not a Decision. Match rules and match methods, reconciliation rules, and why a unified profile isn’t a golden record.
- When Authority Is Shared. Requests vs updates, loops and collisions, split-mastered hierarchies, and one customer in two ERPs.
- The Checkpoint 1 challenge, then Checkpoint 1: Steve Trucking, What I Would Architect. Try the challenge first: draw and defend the Part 1 design, then compare it with mine, and see what changes from chapter 4’s landscape.
When you’ve finished, check yourself with the chapter study guide: a checklist for the exam, the habits beyond it, the words to know, and a few questions. It closes Part 1; the Part 1 study guide puts all six chapters together.
What an architect decides here
Section titled “What an architect decides here”- Which system is authoritative for each important attribute, and how that shows in the model.
- Which mastering style fits each data domain, and how much authority the mastering layer gets.
- When to merge, when to link, and who owns each survivorship rule.
- How strict matching should be, based on what a false match costs.
- Where two-way data and shared hierarchies need explicit boundaries.
Beyond the exam: agents need one identity to act on, and that raises the stakes both ways. Over-matching becomes a privacy incident, and an agent that “updates the customer” has to write to each attribute’s system of record, not to the unified profile. Each module ends with what AI changes.
Explore
Section titled “Explore”- Salesforce Architects, Data 360 Architecture (opens in a new tab), checked 2026-10-14.
- Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab), Identity Resolution Match Methods (opens in a new tab) and Identity Resolution Reconciliation Rules (opens in a new tab), checked 2026-10-14.
Next: Part 2 begins with Designing for Scale (coming soon).