Study guide
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)
Study guide for chapter 6 of the Data Architect course. Read the six modules first, including the Checkpoint 1 walkthrough; this page helps you check what stuck.
About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.
This chapter carries the exam’s Master Data Management section (5%) and the single view of the customer from Salesforce Data Management. It’s a small section by weight, but its ideas (authority, matching, survivorship) show up inside many other scenarios. Platform numbers change, so check the current ones before you rely on them.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
MDM-2: a golden record and a system of truth
- I know authority is assigned per attribute, not per record: one account can have fields mastered in the ERP and fields mastered in Salesforce. (Truth Belongs to an Attribute)
- I ask where each attribute is created, edited and referenced, and its latency of change. (Created, Edited, Referenced, and How Fast?)
- I can build an authority map, and I know the business owner and the authoritative system aren’t the same thing. (Build an Authority Map)
- I know authority can change over the lifecycle (a prospect in Salesforce becomes an ERP-governed customer), and that a copy isn’t authority. (Authority Changes Over the Lifecycle, A Copy Isn’t Authority)
MDM-1: MDM techniques
- Test knowledge: I know the four MDM implementation styles, registry, consolidation, coexistence and centralized: what each centralizes and whether it pushes values back. (The Four Side by Side)
- I can tell the four MDM styles apart: registry, consolidation, coexistence and centralized, and choose the lightest one that solves the problem. (The Four Side by Side)
- I know a canonical data model harmonizes structure, but doesn’t decide authority. (A Common Model Isn’t a Common Truth)
- I know the order: harmonize, then match, then consolidate. (Harmonize, Then Match, Then Consolidate)
- I know thresholds reflect tolerance for error, and enrichment needs provenance. (Thresholds, Review and Enrichment)
- Test knowledge: I know hierarchy management: Parent Account builds the hierarchy (the Lightning view shows up to 2,000 accounts, without person accounts), hierarchies are often split-mastered, and a company can have several valid hierarchies. (Hierarchies Are Master Data Too, One Hierarchy, Several Masters)
MDM-3: choosing the winning attributes
- I keep matching, merging and survivorship apart. (Matching, Merging and Survivorship)
- I know the survivorship rules: most recent, most frequent, source priority, and that every rule needs an owner. (Survivorship: Which Value Wins?)
- I know a match doesn’t require a merge, and I merge only with a clear winner, deciding first what happens to the children. (A Match Doesn’t Require a Merge, My Merge Rule: a Clear Winner)
- Test knowledge: I know what a Salesforce account merge does: up to three records, one principal, the oldest Created By and Created Date kept, the others to the Recycle Bin, and contact point objects not merged for person accounts. (What a Salesforce Merge Actually Does)
SDM-3: a single view of the customer
- I know Data 360 identity resolution links source profiles into a unified profile and keeps the links back: closest to a registry. (Identity Resolution Answers “Who?”)
- Test knowledge: I know Data 360 match rules: all criteria in a rule must match, any rule can match; more criteria for accuracy, fewer for consolidation. (Match Rules)
- I know the match methods (Exact, Exact Normalized, Fuzzy at three precisions): a less precise method raises consolidation, and the risk of false matches. (Match Rules)
- Test knowledge: I know reconciliation rules (Last Updated, Most Frequent, Source Priority) decide what the unified profile shows, but don’t change the sources; contact points aren’t reconciled. (Reconciliation Still Isn’t Mastering)
- I can choose between duplicate management, identity resolution and a dedicated MDM platform for the job. (Three Tools for Three Jobs)
MDM-4 and two-way data
- I know two-way data doesn’t mean two masters: a Salesforce edit to an ERP-owned field is a request, so design request → validate → accept → publish, with a pending state. (Two-Way Data Doesn’t Mean Two Masters, When the Master Says No)
- I know how to avoid loops and collisions: tell an originating change from its echo, and decide which fields travel together as one transaction. (Loops and Collisions)
- For one customer in two ERPs, I can choose a hierarchy, peer accounts or one account with a child per ERP, by how well the client keeps its ERPs in sync. (One Customer, Two ERPs, Ask How They Keep the ERPs in Sync)
Checkpoint 1: putting Part 1 together
- Test knowledge: I know which external licenses carry standard sharing: Customer Community Plus and Partner Community, which need roles for the external users; Customer Community uses sharing sets. (Who Sees What, and Who Needs a License)
Beyond the Exam
Section titled “Beyond the Exam”The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.
- “Single source of truth”: which truth? It’s an architecture of truth, not one record.
- Make authority visible in the schema: a prefix for fields another system owns.
- Trust needs more than a value: source, last confirmed, who changed it.
- Start with the problem, not the MDM product. MDM is a business decision about authority.
- Linking isn’t mastering.
- Where false matches are costly, under-match on purpose.
- Keep duplicates from external loads when you may need to trace back.
- A unified profile is a map. A golden record is a decision.
- Presentation isn’t authority.
- Unifying identity doesn’t erase security boundaries.
- The hardest thing are the bi-directionals. Shared authority isn’t the problem; ambiguous authority is.
- Never let a rejected request turn into competing truth.
- A field that says this is master data drives editability, not a record type.
- We don’t control the ERPs. We control how we represent them in Salesforce.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Master data management (MDM) | Establishing and governing the authoritative identity and values of key data across systems |
| Authority map | For each attribute: who creates it, who owns the decision, which system is authoritative, who may change it |
| Golden record | A governed decision about which values are authoritative |
| Hybrid golden record | A record with some attributes mastered elsewhere and copied in, and some owned locally |
| Registry | MDM that links records as the same entity without changing the sources |
| Consolidation | MDM that combines data centrally, usually for analytics, without pushing back |
| Coexistence | MDM that decides the mastered value and publishes it back to the sources |
| Centralized MDM | MDM where governed data is created in the master and distributed |
| Canonical data model | An agreed enterprise shape for a concept, used to map systems to one another |
| Harmonization | Making values comparable: standard formats, codes and abbreviations |
| Matching | Deciding whether records represent the same thing |
| Survivorship | Rules for which value wins when sources disagree |
| Principal record | In a Salesforce merge, the record that survives and keeps its hidden and read-only fields |
| Match method | How a Data 360 match criterion compares values: exact, exact normalized or fuzzy |
| Identity resolution | Data 360’s matching of source profiles into unified profiles |
| Unified profile | A set of keys linking source records that represent one person or company |
| Reconciliation rules | Data 360 rules for which value a unified profile shows |
| Split-mastered hierarchy | A hierarchy whose branches are owned by different systems |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. "Salesforce is our single source of truth for the customer." What do you ask?
Which truth? Authority is per attribute: the ERP may own the legal name, billing address and credit limit while Salesforce owns the account executive and success tier. Build an authority map. Reread Truth Belongs to an Attribute.
2. Service agents need to see that a Salesforce contact is the same person who bought online. Nobody needs the systems to change. Which MDM style?
A registry: link the records as one identity without changing the sources, which is what Data 360 identity resolution does. Choose the lightest pattern that solves the problem. Reread Registry: Tell Me Who Is Who.
3. Survivorship is set to "most recent wins" for every field. Someone changes the Salesforce copy of the ERP-owned legal name. What happens, and what's wrong?
The newest value wins, and the copy overrides the authority. “Most recent” is a statement about trust that fits some attributes (a mobile number) and not others. Where the authority map says the ERP owns the field, the ERP wins. Reread Survivorship: Which Value Wins?.
4. Legacy customer records are imported and match existing accounts. Merge them?
Be cautious. A match doesn’t require a merge, and merging destroys the legacy IDs and older values you may need to trace. Link them, unless there’s a clear winner and the duplicate adds nothing you need. Reread My Merge Rule: a Clear Winner.
5. The unified profile in Data 360 shows Dallas. The team says Dallas is now the golden value for every system. Is it?
No. Reconciliation decides what the unified profile shows; it doesn’t change the sources or make a mastering decision. If every system must use one governed value, that’s coexistence or centralized MDM, with an owner. Reread Reconciliation Still Isn’t Mastering.
6. Matching medical records versus marketing records: same rules?
No. A false match in marketing sends the wrong offer; in medical data it combines two people’s histories. Set strictness by the cost of being wrong, and under-match where blending is costly. Reread The Cost of Being Wrong.
7. Reps want to update an ERP-owned billing address from Salesforce. How do you design it?
As a request, not an edit: Salesforce sends the proposed value, the ERP validates and accepts it, and publishes the authoritative value back. Hold a pending state until then, and handle rejection, collisions and echoes. Reread Two-Way Data Doesn’t Mean Two Masters.
8. At Steve Trucking, the same John Smith appears in two Retail Partners' manifests. Unify him?
No, deliberately. Each partner must never see another’s Recipients, and a unified identity is the bridge that leaks. Under-match where blending is costly; if a partner wants repeat recognition, scope it to that partner only. Reread Would I Unify Recipients Across Partners?.
9. A rep sends a new street for an ERP-owned address while, the same minute, someone in the ERP changes the city. What do you decide?
Whether the address travels as one transaction. If it does, the fields all go together or none do, and the request is rejected because the address changed in the meantime. Decide that before the first collision, and remember the request is asking to change the ERP’s value, not changing it. Reread Loops and Collisions.
10. A client has one customer in two ERPs, and nobody keeps the two records in sync. Sales wants one account. What do you recommend?
Not one account. If they can’t keep the records in sync in their own ERPs, Salesforce can’t do it for them: represent them as peer accounts or a hierarchy, and show the structure sales already knows. One account with a child per ERP needs a client that keeps the shared values in sync. Reread Ask How They Keep the ERPs in Sync.
Explore
Section titled “Explore”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-09-25): the official list of objectives and their weights. Always check the current version before you book the exam.
- Each module’s own Explore section lists the Salesforce documentation behind its facts, with the date checked.