Merging and Unmerging

A merge combines duplicates into one record. The important property is that it is reversible.

Where to find it

These features have no dedicated Architect Panel section of their own. They are configured through their datastores, opened from All Datastores, and most of what a caseworker sees appears on the record itself rather than on an admin screen.

What a merge does

One record survives and the others are folded into it, with their cases, correspondence and history reattached to the survivor. What was on the merged records is not discarded — it moves, and the fact that it moved is recorded.

Choosing the survivor

Usually the one with the most complete history, not the most recent. Where one record carries a reference quoted to the outside world — a client number, a case reference on a letter — that is a strong reason to keep it, because the outside world will keep using it.

Review before merging

Merging is not the place to be efficient. Look at both records, particularly dates of birth, addresses and any identifier. Two people genuinely can share a name and a street, and a merge that joins them creates a single record containing two people's data — which is a data protection incident, not a tidiness problem.

Unmerge

Unmerge exists because the above happens anyway. It 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 — but it means a mistaken merge is recoverable rather than permanent.

After a merge

Check anything that referenced the merged record by identifier, particularly outbound integrations. A merge that is clean internally can still leave an external system pointing at a record that is now a redirect.