Records
Nothing merges two records on its own. Ever.
Automatic merging is the feature everyone asks for and nobody survives. It is right most of the time, and the times it is wrong it destroys a relationship history in a way nobody notices for a quarter.
So the product finds them, explains why it thinks so, and stops.
Finding them
A pair only appears if something specific matched.
Not a confidence number on its own. A suggestion is raised when a named field actually matched — a near-identical name together with the same web domain, or a shared email address, or a name plus a phone number plus a shared account. Confidence alone, with nothing you could point at, never promotes a pair.
Which is the difference between a queue somebody works and a queue somebody mutes.
Nothing merges on its own. A pair you dismiss can legitimately come back if the two records later drift together — which is the behaviour you want, and the reason the queue does not simply remember a no forever.
- Web addresses are compared as companies, not as strings —
A full address with a path, and the bare domain, are the same company. The scheme, the port, the path and the leading www are all ignored.
- A phone match needs enough digits to mean something —
Short internal extensions cannot manufacture a match, and everything that is not a digit is ignored, so formatting differences never matter.
- Capped per save, so one common name cannot flood the queue —
A handful of candidates at a time. Without the cap, adding a company with a very common name raises dozens of suggestions in one write and the queue stops being worked.
- The scan never blocks a save —
If the duplicate check itself fails, the record is still created and the failure is logged. Nobody is ever stopped from entering a customer because a background check had a bad moment.
- A dismissed pair can legitimately return —
If the two records later drift together — somebody adds the matching domain — the pair is raised again. A no is about these two records as they are, not for ever.
Merging
Merging moves everything, and the build breaks if that stops being true.
Every relationship that points at the record being absorbed is moved to the survivor — activities, notes, tasks, deals, quotes, documents, the lot.
That is easy to say and hard to keep true. The usual failure is silent: a later part of the product adds a new link, nobody remembers to update the merge, and from then on every merge quietly strands part of a timeline.
So the relationships are declared in one place, and a test fails the build when a new one is added without being declared. A recurring class of bug converted into something that cannot reach a release.
- Blanks on the survivor are filled from the loser —
Across eighteen named fields for a company, eleven for a person. The record of the merge lists which fields were filled, by name.
- Where both disagree, the survivor wins —
There is no field-by-field choice at the moment of merging, and no unmerge. Choose the survivor deliberately.
›Can I run a scan across everything we already have?
Yes, on demand. It works through the most recent records first, so on a very large workspace the oldest duplicates may need more than one pass — worth knowing if you are cleaning up after an import.
›Are leads included?
Not in this queue. A lead is checked for an exact email match when it is created, which catches the common case; the fuzzy queue covers accounts and contacts. Two spellings of the same lead with different addresses will not surface here.
›Does it re-check when I edit a record?
The scan runs when a record is created. Renaming an account into collision with another is caught by the next workspace-wide scan rather than immediately.
›Is this the same as merging two people?
No, and the difference matters. The person record underneath — the one that spans candidate, contact and employee — has its own merge, with a field-by-field choice and thirty days to undo it exactly. This queue is about two CRM records. See the one-record page for the other.