Lookalikes
Two records. Two histories. Two different answers to the same question.
Lookalikes finds records that look like duplicates of each other, even when they are not written exactly the same way — "Acme Ltd" and "ACME Limited" — and helps you merge them safely.
Why this exists
A unique or combination-key business rule stops an *exact* duplicate from being created. It cannot catch two records that describe the same real thing but are typed differently. Lookalikes is built for that gap.
How it will work
- Turn it on per entity, and choose whether it checks for values that are exactly the same or just similar.
- Pick which fields to compare, and mark each one as either must be close (the record cannot match without it) or counts as extra proof (raises confidence, but is not required on its own).
- Every save — typing in the grid, pasting, a file import, staging, or the REST API — is checked automatically, in the background. Nothing is ever blocked because of a possible match.
- A likely match is added to a review queue, never merged automatically.
- A reviewer compares both records side by side, picks the winning value for every field, and picks which record survives.
- The merge goes through the same approval step as any other change — a second person signs off before anything is combined. Every reference the losing record had is moved to the surviving one, and the merge is written to the audit log.
What it will not do
It will not merge anything without a person approving it first, and it will not silently delete data — the losing record's history stays in the audit log after the merge.
Questions
Can I undo a merge?
No. The merge is written to the audit log and the losing record's history stays there, so you can see exactly what was combined and by whom — but putting the two records back apart is manual.
Does it check on every save, or only at night?
Both, and you choose. A scheduled run goes over the whole entity; every save is also checked in the background. Nothing is ever blocked at the point of entry because of a possible match.
What happens to the record that loses?
Every reference it had — orders, invoices, child records — is moved to the surviving record first, so nothing is left pointing at nothing. Its history stays in the audit log.
Will it match on a field that is empty on one side?
No. A field missing on one side does not count for or against the pair; it simply does not vote.
Why is a pair I can see with my own eyes not being offered?
Almost always a field marked must be close that did not come close. That kind of field is a gate: it can refuse a pair on its own, however well everything else agrees.
Related
- Business Rules Overview — stops exact duplicates at the point of entry
- Approval Workflows — the review step a merge goes through
- Audit Log — where a merge's history is recorded