Matching, Merging and Survivorship

🌐 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)

Image generated with AI

Module 3 of 6 in the chapter Master Data and Identity, chapter 6 of the Data Architect course. Each module stands on its own. Previous: The Four Ways to Master Data · Next: A Map Is Not a Decision

The question this module answers: How do you find duplicates, and decide which values survive?

Salesforce has two contacts: Daniel Reyes, Dallas, d.reyes@example.com, and Dan Reyes, Dallas, d.reyes@example.com. Same person? Probably. Should we merge them? That’s a different question. And if we do, which phone number, address and title survive? Different again. Architects need to keep three decisions apart:

• Matching: do these records represent the same thing?
• Merging: should they become one record?
• Survivorship: if we combine data, which values win?

Matching Comes First

Chapter 3 covered Salesforce’s duplicate and matching rules, so I won’t reteach the mechanics. The architectural question is what evidence is strong enough to say these might be the same? For a person: email, phone, name plus address, a customer number, some combination. For a company: legal name, tax ID, ERP customer ID, address, web domain. Not “can Salesforce compare these fields?” but “what combination gives us enough confidence to act?”

And exact isn’t certain. A shared email is a strong signal, not proof: families share addresses, businesses use purchasing@company.com, phone numbers belong to households, names and addresses aren’t unique, and even strong identifiers get reused, mistyped or recycled. Matching isn’t string comparison. It’s a statement about identity.

The Cost of Being Wrong

When I teach this, I change the domain. In automotive marketing data, we wrongly decide two Daniel Reyeses are the same person, and the wrong one gets an offer for an SUV. Not good, but low risk. Now make the same false match in medical data: two different people’s medical histories combined. Same matching error, completely different consequence. That’s why there’s no universal “good” matching threshold. Sometimes the bigger risk is missing a match; sometimes it’s combining two people who aren’t the same. Where false matches are costly, I deliberately under-match.

Harmonize, Then Match, Then Consolidate

Matching also depends on the data’s shape. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Harmonization makes values comparable: standard formats, normalized abbreviations, mapped codes. Then you match. Only after records are known to belong together do you consolidate their information into one representation. Harmonizing isn’t matching, matching isn’t merging, and consolidating isn’t necessarily mastering.

Click to enlarge

Identity decisions happen in stages.

A Match Doesn’t Require a Merge

This is one of the most important distinctions in the chapter. We’re confident two customer records from two old systems are the same company. Do we have to merge them? No. Each may carry a source-system identity; historical transactions may point at each; auditors may need the trail; we may still be migrating; we may need to know exactly what the old system said. Knowing two records are the same thing doesn’t force us to collapse them. We can link them, and that’s often the safer architecture.

My Merge Rule: a Clear Winner

My position: merge only when there’s a clear winner and the duplicate adds nothing you need to keep. A rep created a duplicate account yesterday; the original is clearly the established record. Good merge candidate. Now change it: we imported customers from a legacy system, with its own IDs, older values, maybe transactions or audit requirements tied to them. I’m much more cautious. Keep duplicates from external loads when you may need to trace back to older values, because merging destroys that history.

What a Salesforce Merge Actually Does

A link says “these belong together.” A merge says “these are now one,” and on Salesforce it’s a real change. For accounts, you select up to three records and choose one as the principal; you pick which of the others’ field values to keep, while hidden and read-only fields come from the principal. The merged record keeps the Created By and Created Date of the oldest record, whichever is principal. The non-principal records go to the Recycle Bin. Related records such as activities move to the merged record, with exceptions. In Lightning, merge works on the duplicates your duplicate rules detect. And for person accounts, contact point objects don’t support merging: their relationships are lost (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab)).

Test knowledge. Know what a Salesforce account merge does: up to three records; one principal, whose hidden and read-only fields are kept; the Created By and Created Date of the oldest record, whichever is principal; the other records go to the Recycle Bin; and for person accounts, contact point objects aren’t merged.

You don’t need every edge case to make the decision. You need the consequence: after a merge, the independent records you started with are gone. Chapter 1’s Reversibility Test applies: linking is easy to undo; merging isn’t. And a customer rarely stands alone: contacts, cases, opportunities, files, consent records, custom children, external IDs, integration references. Before merging the parent, understand what happens to everything attached to it. When duplicates come in with a load, I give teams three choices for the children: move them to the surviving record; don’t load them at all, if nobody needs them; or keep them on the other record, marked inactive, so they still turn up in search. The first is what a merge does for you. The other two keep the trail, and that’s often the point.

Survivorship: Which Value Wins?

Records belong together, but they disagree: Salesforce and billing say 602-555-0100, the ERP says 602-555-0188. Survivorship rules pick the winner. The common ones: most recent (the latest update), most frequent (the value most sources agree on), and source priority (trust this source over that one), plus combinations, thresholds, weights and business-specific rules. None of them is inherently right.

“Most recent” isn’t a technical setting. It’s a statement about trust: when systems disagree, the newest value is more likely correct. Reasonable for a mobile number. Terrible for a legal name: if the ERP owns it, I don’t care that someone changed the Salesforce copy five minutes ago. “Most frequent” assumes agreement is evidence, but three stale downstream copies don’t outvote the source of record. “Source priority” says it plainly: we trust this source more. So survivorship belongs in architecture and governance, and every rule needs an owner. Who decided the newest address wins, or that the ERP outranks Salesforce?

If module 1’s authority map already says the ERP owns the credit limit, survivorship is easy: the ERP wins, no clever scoring needed. The hard cases are attributes where authority is shared, unclear or based on evidence rather than one master. That’s where survivorship rules earn their keep.

Click to enlarge

Survivorship rules are statements about trust.

Thresholds, Review and Enrichment

Some matching weighs the evidence: a customer ID match is very strong, an email strong, a phone moderate, a similar name weak, a similar address supporting. Above one score, a match; below another, different; in between, a person reviews it. The algorithm isn’t the lesson. The threshold is your tolerance for error, and it should follow business risk. And when the evidence raises the question without settling it, don’t pretend the system knows. Route it for review. Slower, and that’s fine: automation isn’t valuable when it confidently merges two different customers.

Enrichment adds another provenance question. Postal reference data, industry codes, firmographics, external risk scores improve master data, but where did each value come from, how reliable and current is it, may we use it for this purpose, does it hold personal data? “Industry = Transportation” from a data provider isn’t the same as the customer telling you. Keep that distinction.

Steve Trucking: Similar Isn’t Same

Two Retail Partners send deliveries to John Smith, 123 Main Street, Columbus, with the same phone number. Same person? Probably. Should Steve Trucking unify them? Remember whose they are: those Recipients are the partners’ customers, and one partner must never see another’s. A false match would blend data across that boundary. Suddenly it isn’t a data-quality question but a privacy and isolation question, which is exactly why thresholds depend on consequences. The checkpoint makes the call. For now: don’t let matching convenience make the business decision.

Sometimes keeping the mess tells you something. This record came from the old system, that one from Salesforce, this one from the acquired company; their IDs, their history and the fact that they disagreed may all matter. Clean data is valuable. So is traceability. The architect decides which matters more for the use.

Beyond the exam: what AI changes. A bad match used to mean two emails or a split service history. Now an agent finds what it thinks is the customer and pulls their orders, cases, addresses and notes. If two people were wrongly matched, it can act on one person’s information for another. The matching decision has become part of the security boundary, and where blending is costly, stricter matching is the safer design.

What an Architect Decides Here

• What evidence is enough to flag a possible duplicate in each data domain.
• Whether a confirmed match becomes a merge, a link or a human review.
• Which values survive disagreement, and who owns each survivorship rule.
• How much false-match risk the business can tolerate versus missed-match risk.
• Which source identities, history and related records must be preserved before any merge.

Match carefully, merge deliberately, choose survivorship rules intentionally. A clean customer record isn’t worth much if you got there by combining the wrong customers.

Explore

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) and Merge Duplicate Accounts in Lightning Experience (opens in a new tab), checked 2026-10-14.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab), checked 2026-10-14.