The task
Duplicate records are easy to find and dangerous to merge. Two customers at the same address may be one record entered twice or two genuinely different accounts, and an automated merge gets that wrong quietly. Configure an agent to present candidate pairs with the evidence on both sides, and leave the merge to a person who can be accountable for it.
What you provide
The record extract
The records under review with the fields that identify them, and the created and last-updated dates.
Your merge rules
What makes two records the same in your business, which fields are authoritative and which differences rule a pair out.
Related activity
Optional but valuable. Transactions or interactions attached to each record, because activity on both is the strongest signal that they are genuinely different.
Give the agent a clear brief
Use these instructions as a starting point, alongside your approved sources and permissions.
Identify candidate pairs using the supplied rules. For each pair, present the evidence that they are the same and the evidence that they are different, quoting the fields. State which fields disagree. Do not merge, update or delete any record, and do not rank pairs by a similarity score presented as a probability.
How the work comes together
Find the candidates
Apply the supplied rules rather than a general notion of similarity, so the pairs surfaced are the ones your business would call duplicates.
Argue both sides
Set out what agrees and what disagrees for each pair. A shared address with different tax identifiers is a pair to leave alone, and that only shows up if the disagreement is presented.
Return pairs, not verdicts
Hand the data owner the evidence and let them decide. A merge is close to irreversible and should never be the output of a confidence threshold.
Illustrative example · fictional data
Two pairs, opposite answers
An illustrative review of a fictional customer extract, with rules treating the tax identifier as authoritative.
| Candidate pair | Agrees | Disagrees |
|---|---|---|
| Records 8821 and 9134 | Name, address, tax identifier | Only the spelling of the street |
| Records 4402 and 4407 | Address and contact surname | Tax identifier, and both have recent activity |
| Records 7710 and 7711 | Name and tax identifier | One has no activity and no created date |
The second pair is the one an automated merge would have destroyed. Two active accounts at one address with different tax identifiers are usually two real businesses.
The human review
A data owner decides every merge and runs it through your existing master data process. The agent presents evidence and never changes a record.
Set it up for your team
Write down what makes records the same
Name the authoritative fields and the differences that rule a pair out. Without them, this becomes generic string similarity, which is where bad merges come from.
Supply activity where you can
Activity on both records is the strongest evidence that two similar records are genuinely different entities.
Keep merging manual
Configure the playbook to stop at evidence. A merge is close to irreversible and belongs with an accountable owner.
Check the result before scaling
Use a set where the answers are known, including pairs that look identical but are not. Measure pairs missed and, more importantly, pairs presented as strong candidates that should never be merged.
Keep the data in the right place
This playbook reads across a whole record population, which is a larger exposure than any single document workflow. A local deployment keeps the extract and the review inside your network.
Explore deployment optionsQuestions & answers
Can it merge the duplicates automatically?
No, by design. It presents evidence for a person to decide, because a wrong merge is close to irreversible and often discovered months later.
Why is there no confidence score?
A score invites a threshold, and a threshold invites automatic merging. Evidence on both sides gives a data owner something they can actually check.
What if two records look identical but are different?
That is the case the evidence view exists for. Disagreeing fields and activity on both records are presented prominently rather than averaged into a score.