Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Duplicate contact merger series ~5 min read

How a merge gets proposed

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)
  • Phone. A: 07700 900123 · B: empty · Result: 07700 900123
  • 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

How a merge decides which value wins for each fieldA vertical chain of five steps entered by a box labelled One field, two values, A and B. Step one asks whether one is empty; if so the other wins, which covers most cases. Step two asks whether they are identical; if so no decision is needed and it counts as evidence. Step three applies the rule for that field from a one-per-field rule set, such as most complete or most recent. Step four asks whether both can be kept, as alternates, tags or appended notes; if so it exits to Keep both, so nothing is lost. Step five is one wins and one is lost, which is highlighted. A note says most fields never reach the last step and the ones that do are what a person checks.AWS ACCOUNTOne field, two valuesA and BOne empty?The other winsmost of the casesyesIdentical?No decision neededand it is evidenceyesA rule for this field?most complete, most recentField rulesone per fieldCan both be kept?alternates, tags, notesKeep bothnothing is lostyesOne wins, one is losthighlight itMost fields never reach the last step. The ones that do are what a person checks.
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.

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.

The related records a contact merge has to moveA horizontal row of five boxes. The record: one row. Orders: four move. Messages: eleven move. Notes: two move. All counted: and all reversible. A note says showing the counts is what makes the scale of the change visible before confirming.A MERGE MOVES MORE THAN A ROWThe recordone rowOrders4 moveMessages11 moveNotes2 moveAll countedand all reversibleShowing the counts is what makes the scale of the change visible before confirming.
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.

Next: undoing one.

All posts