Research question
When two CRM records appear to describe the same account or contact, which record should survive the merge, and what evidence shows that the decision did not discard a material customer or pipeline fact? A duplicate counter can report volume, but it cannot answer that question. A merge can reduce row count while losing an account owner, an opt-out, a recent activity, or the relationship between an opportunity and its contacts.
This study treats duplicate resolution as an evidence problem rather than a cleanup contest. The NIST Cybersecurity Framework 2.0 organizes risk work around governance, identification, protection, detection, response, and recovery. The NIST Privacy Framework adds questions about processing, accountability, and data protection. Neither framework tests a CRM merge. They provide a useful boundary for deciding what a local study must record.
What the evidence says
The available sources point to a control pattern, not a universal merge formula. NIST asks organizations to know their systems, responsibilities, data, and response paths. NIST SP 800-53 describes control families that include access, audit, configuration, and system integrity. The FTC guide to protecting personal information emphasizes knowing what information is held, limiting unnecessary retention, protecting it, and disposing of it safely. Salesforce documentation describes duplicate management as a combination of matching and duplicate rules, which is a product capability rather than evidence that a particular merge is correct.
The practical inference is narrow: a merge study should preserve the inputs, the match reason, the fields that conflict, the approver, and a recovery path. It should not claim that any source proves a specific survivorship rule. A company may decide that the freshest verified phone number wins, that the account owner must be preserved, or that consent evidence always overrides freshness. Those are local policies and need an owner.
Study design
Start with a bounded population. Choose one object, one time window, and one matching signal such as normalized domain, exact email, or account identifier. Record the query or export checksum so another reviewer can reproduce the sample. Separate high-confidence pairs from ambiguous pairs before any merge is proposed.
For every pair, record the following evidence:
| Evidence | Question answered | Stop condition |
|---|---|---|
| Identity | Why are these records believed to represent one entity? | Signals conflict or are too weak |
| Ownership | Which owner, team, and territory should remain? | Ownership is disputed or missing |
| Consent | Which opt-out, permission, or source history must survive? | Consent history cannot be reconciled |
| Activity | Which meetings, tasks, and opportunity links are material? | Links would be lost or reassigned blindly |
| Recovery | Can the original state be restored and audited? | No export, log, or rollback path exists |
Sample both proposed merges and proposed non-merges. The second group matters because a model or rule can look accurate by selecting only easy duplicates. Include shared domains, household addresses, role changes, subsidiaries, and records with different owners. A support specialist can prepare the evidence table. The accountable CRM or sales owner should decide ambiguous survivorship.
Survivorship hypotheses to test
Do not begin with the assumption that the newest row is the best row. Test explicit hypotheses against a labeled sample. One hypothesis might say that a verified account identifier outranks a name match. Another might say that an opt-out or permission restriction survives regardless of which record is newer. A third might say that an active opportunity link requires owner review before merging.
For each hypothesis, calculate false merges and missed merges separately. A false merge combines distinct entities. A missed merge leaves duplicate work and reporting noise. These errors have different consequences, so one accuracy number hides the decision tradeoff. Report counts by signal type, object, owner group, and exception reason. Keep the denominator visible.
Run a pre-merge preview. Capture the two source records, the proposed winner, field-level conflicts, related-object links, attachments, campaign or consent history, and the person who approved the action. If the CRM cannot provide a complete preview, reduce the batch size and retain a before export. A procedure that cannot show what would be lost is not ready for unattended execution.
Role boundaries and recovery
The preparation role can normalize values, collect sources, flag conflicts, and assemble a review queue. It should not decide that a customer identity is the same when the evidence is ambiguous, alter consent status, transfer ownership to resolve a queue, or delete a record solely because a rule produced a match. The decision owner should document the exception and the reason.
Recovery is part of the research design. Keep a read-only before snapshot, merge identifiers, timestamp, actor, approval, and post-merge verification. Test one restoration case before scaling. If a merge cannot be reversed, treat that limitation as a risk result, not a footnote. NIST control guidance and FTC data-protection guidance both support making access, retention, and accountability explicit, but they do not prescribe a product-specific rollback method.
Conclusion
The research question has a conditional answer. The record that survives should be the one selected by a tested, local survivorship rule that preserves identity, ownership, consent, activity, and recovery evidence. There is no defensible basis for choosing the newest or most complete-looking row without checking those dimensions. A five-field duplicate count is therefore an inadequate release gate.
SalesSupportStaff can prepare bounded duplicate evidence, source references, and exception queues for review. The internal owner should retain decisions about identity, consent, ownership, and irreversible changes. The useful outcome is not a lower row count by itself. It is a reproducible merge decision another reviewer can inspect and safely challenge.
For an operating comparison, pair this CRM duplicate merge survivorship study with the CRM duplicate prevention guide and the CRM import quality guide. Those Blog articles address practical support work; this study supplies the evidence questions that determine whether a proposed merge is safe to review. Keeping the research question separate from the operating guidance helps a reader distinguish a measured finding from a recommended workflow.
One useful output is a survivorship decision table. List the field, both source values, the evidence authority, the selected value, the approving owner, and the reason for rejecting the alternative. Add a column for related objects so that a contact merge does not silently detach an opportunity or an account merge does not erase a territory relationship. Review the table after the batch, not only before it. A rule that seemed safe in a small sample may create an exception pattern at scale. Record the pattern, pause the rule if necessary, and send the policy question to the system owner.
Keep rejected pairs in the study. They show whether the matching rule is too broad and give the next reviewer a negative control.
Sources
- NIST Cybersecurity Framework 2.0, used for governance, identification, detection, response, and recovery context.
- NIST Privacy Framework, used for processing, accountability, and data protection context.
- NIST SP 800-53 Rev. 5, used for access, audit, configuration, and system-integrity questions.
- FTC Protecting Personal Information, used for data minimization, protection, and disposal context.
- Salesforce duplicate management guidance, used only to describe matching and duplicate-rule product concepts.