Parties, Duplicates & Merge
Find the same person recorded three ways, merge them safely, and unmerge when a merge turns out to be wrong.
Duplicate Detection and Matching
The same person arrives as "Rob Smith", "Robert Smith" and "R Smith, 14 High St", and a system treating them as three people gives three partial histories and no complete one.
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.
Fuzzy rather than exact
Exact matching finds only the duplicates nobody would have missed. Matching allows for spelling variation, name order, transposed digits and formatting, because that is what real data contains.
Scoring, not deciding
Matching produces a score and a candidate list rather than a verdict. That is deliberate: automatic merging on a confident-looking score is how two different people with the same name and street become one person, which is far harder to unpick than leaving them separate.
Tuning the threshold
Set it so review is realistic. Too loose and the queue is full of pairs that are obviously different; too tight and you only catch what you would have caught anyway. Start conservative, review what it finds, and loosen once you trust it.
Conflict checking
For a legal practice this is also conflict checking. Run matching on the parties before a matter opens rather than after — a conflict found at file opening is an awkward conversation, and the same conflict found three weeks in is a professional problem.
The sweep
The Duplicate Detection Sweep task looks for new candidates in the background. It ships disabled; daily is usually right, because duplicates accumulate steadily rather than suddenly.
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.