A merge proposal that shows the resulting record looks complete and hides the only thing worth looking at. Everything that makes a merge dangerous is in what disappears, and a person scanning a proposal for four seconds will see it only if it is on the screen.
Key takeaways
Show three columns: record A, record B, and the result.
Field rules decide the default; most-complete and most-recent cover nearly everything.
Anything that would be lost is highlighted, including free text and tags.
Related records — orders, notes, messages — move, and the count is shown.
One button to confirm, one to reject, one to keep both values where the system supports it.
Three columns
What a proposal shows
Name. A: J Reed · B: Jonathan Reed · Result: Jonathan Reed(most complete)
Email. A: j.reed@old.example · B: jonathan@new.example · Result: jonathan@new.example(most recent; the other is kept as an alternate)
Notes. A: “prefers email, no calls before 10” · B: empty · Result: kept
Would be lost: nothing.
Related: 4 orders and 11 messages from A move to the merged record.
The fifth line is the one that changes behaviour. In this example it says nothing, which is a two-word confirmation that the merge is safe. When it says “A’s address, A’s company name, and a note from 2024”, somebody stops and reads.
Which value wins
Fig 1. How each field’s value is decided. The keep-both branch is worth implementing wherever the target system allows it, because it removes the loss entirely.
App integration
Machine learning
Networking
Management
Analytics
Keep both wherever possible
A surprising number of fields do not actually require a choice. Two email addresses can usually be a primary and an alternate. Two phone numbers can be mobile and landline. Tags are a union. Notes can be appended with a dated separator rather than one overwriting the other.
Every field moved from “one wins” to “keep both” removes a loss and therefore removes a reason for somebody to hesitate over a proposal. It is worth going through the field list once specifically looking for these.
Related records
A merge is not a record edit. Orders, messages, notes, invoices and appointments all point at one of the two records, and a merge has to move them — which is the part that makes a wrong merge genuinely hard to unpick.
Fig 2. What a merge actually moves. The counts on the proposal are what tell somebody whether this is a trivial merge or a consequential one.
App integration
Management
People
The counts also do useful work as evidence. A candidate pair where one record has four orders and eleven messages and the other has nothing at all is very likely a genuine duplicate created by a form submission. A pair where both have substantial history is worth more scrutiny, because two active customers with overlapping details are more often two customers.