Merging and Unmerging
A merge combines duplicates into one record. The property that makes it safe is that it is genuinely reversible.
Where to find it
Architect Panel → Data:
- Merges — every merge, its snapshot, and the unmerge action
- Match Policies — where merge candidates come from
Architect Panel → Security:
- Dual Authorisation — optionally require two people to merge
What a merge does
One record survives and the others are folded into it. Their cases, correspondence, documents and history reattach to the survivor. Nothing is discarded — it moves, and the fact that it moved is recorded.
Unmerge is the constraint that shapes the merge
Before anything is written, a complete snapshot of both rows is taken — not a diff of what the merge intends to change, but the whole of each record as it stood.
That distinction is what makes unmerge trustworthy. A field the merge never touched can still be edited afterwards, and an unmerge built from a diff would silently revert those later edits or fail to restore them. A full snapshot means the engine knows exactly what each record was, independently of what happened next.
Choosing the survivor
Usually the record with the most complete history, not the most recent one. Where one record carries a reference that has been quoted to the outside world — a client number, a case reference on a letter, an account number — that is a strong reason to keep it, because the outside world will carry on using it.
Review before merging
Merging is not the place to be efficient. Look at both records properly, particularly dates of birth, addresses and any identifier.
Two people genuinely can share a name and a street. A merge that joins them creates a single record containing two people's data — which is a personal data breach, not an untidiness problem, and it is reportable. This is the single strongest argument for requiring dual authorisation on merges in a system holding sensitive casework.
Unmerging
Unmerge separates the records again and returns what belonged to each. It is not magic: anything created after the merge has to be attributed by a person, because the system genuinely cannot know which of the two originals a new case belongs to. But it means a mistaken merge is recoverable rather than permanent, which changes the risk of merging from severe to manageable.
After a merge
Check anything that referenced the merged record by identifier, particularly outbound integrations and any system you export to. A merge that is clean internally can still leave an external system pointing at a record that is now a redirect, and that failure surfaces later and elsewhere.
Worked example
Two resident records for the same person, one created by a housing application and one by a council tax registration. The housing record has the longer history and the reference quoted on correspondence, so it survives. Before merging, the reviewer confirms the dates of birth match and the addresses are consistent. After the merge, the council tax integration is checked because it holds the other record's identifier.
Recommendations
- Require two people to merge party records in any system holding sensitive data.
- Merge deliberately and in small batches. A bulk merge run is how two people become one at scale.
- Record why, briefly. "Same person, DOB and NI match" is enough and answers the question later.
- Treat a wrong merge as an incident, not a correction — unmerge it, then work out how the review missed it.