Merging and Unmerging
Merging combines two records into one. The design decision that matters: both original records are preserved in full, which is what makes a merge reversible.
Where to find it
Architect Panel → Data:
- Merges — every merge, its snapshots and its reason
- Match Policies — the policy a merge was made under
Architect Panel → Activity:
- Activity Log — the resulting changes
What a merge records
- The survivor and the merged record.
- The policy and the score.
- A full snapshot of both records as they were.
- A reason.
- Who merged them and when.
- Whether and when it was unmerged, and by whom.
Why snapshots matter
Most systems treat merging as destructive: fields are copied across and one record disappears. If the merge was wrong, the information is gone and the only recovery is a database restore.
Keeping both snapshots means a merge is a reversible decision. That changes how it feels to make one — reviewers can act on a confident judgement without the paralysis of an irreversible action.
Choosing the survivor
The survivor keeps the identity everything else points at. Choose:
- The record with the most activity and history.
- The one other systems reference.
- The one with the better reference number, where one is customer-facing.
Field-by-field, the best value can be taken from either — the survivor is about identity, not about which record had better data.
Field resolution
Where the two disagree, each field's outcome is recorded. Take the more recent or more complete value, but look rather than accepting a default — a merge that quietly discards the only working phone number is a bad merge that looks fine.
Always write the reason
It is what makes the merge reviewable a year later. "Duplicate created by web form on 3 March, confirmed same person by e-mail address and order history" is a decision somebody can check. "Duplicate" is not.
Unmerging
A merge can be reversed, restoring both records from their snapshots and recording who reversed it and when.
Two caveats worth being honest about. First, activity recorded since the merge sits against the survivor and will not automatically redistribute. Second, unmerging is a recovery from an error rather than a routine operation — the reason to unmerge is that the merge was wrong, not that circumstances changed.
Merging two people is a data protection matter
If you combine records for two different individuals, you have disclosed one person's information into the other's record — visible to anybody who can see it, and likely to surface in a subject access request.
Unmerge promptly, and treat it as an incident rather than a correction.
Merge early
The best time is immediately after the duplicate is created, when neither record has accumulated much. A merge decision at that point is easy and low-consequence; the same decision two years later involves reconciling two histories.
Worked example
A reviewer merges two customer records created a week apart, keeping the older as survivor, taking the newer mobile number, and recording the reason. Three months later it emerges they were father and son sharing an address and a landline. The merge is unmerged from its snapshots, both records return, and the two orders placed since are reassigned by hand — recoverable precisely because nothing had been thrown away.
Recommendations
- Merge as soon as a duplicate appears.
- Choose the survivor by identity, then take the best field values from either.
- Always record a specific reason.
- Treat a wrong merge of two people as an incident.