Clean up duplicate records
Connect proposes duplicate pairs; merging them is always a person's decision, never automatic. A merge preserves both sides — identities, lifecycle stages, follow-ups, deals, demos, cases and onboarding all survive — so the risk is not losing data, it is merging two people who genuinely are two people. Check the identities before you confirm, and check the survivor afterwards.
Why duplicates appear at all#
A person is the canonical human and an identity is one address on one channel; one person may hold many. Duplicates arise when the same human reaches you by a route that carries no identity you already hold — a new address, a mobile you had not seen, a message from a personal account about a work matter — and there was nothing to match on at the moment the record was created.
- An import that did not map identities as identities. Everything arrives as new people because nothing could match.
- A call from an unrecognised number. A number that resolves to two rows is resolved to the older one, which is deterministic but not a merge.
- A prospect who is already a customer. Identity resolution exists specifically to stop this, and it is the case worth checking after any discovery run.
- Free-text names. People are not reliably identified by name, and Connect does not treat a matching name as a match.
Working through them#
Open the duplicates view and read the proposals rather than acting on the count. A proposal is a suggestion with reasons, not a queue of chores.
Result You can see why each pair was proposed, which is what lets you dismiss the wrong ones quickly.
For each pair, compare identities first. Two people at one company with similar names and different addresses are two people; the same address on both sides is close to conclusive.
Result You are deciding on evidence rather than on how alike the rows look.
Look at both histories before merging, particularly for open work — an active deal on one side and a support case on the other is the combination that most often reveals two genuinely different people.
Result You know what the merged record will contain before it contains it.
Merge. Both sides' identities, stages, follow-ups, deals, demos, cases and onboarding are preserved on the survivor.
Result One record now answers for the human, and every channel they use resolves to it.
Open the survivor and check four things: the identities are all present, the lifecycle stage is the right one, no follow-up is now duplicated, and any block or suppression that applied to either side still applies.
Result That is the verification. Three of those four are easy to assume and worth two minutes of actually looking.
Merging is a decision, not a cleanup job#
| Situation | Merge? |
|---|---|
| Same address appears on both records | Yes |
| Same mobile number, different addresses at the same company | Usually — check the history first |
| Same name, same company, no shared identity | No. Two colleagues can share a name |
| A prospect record and a customer record for one person | Yes — this is the case identity resolution is meant to prevent, and merging closes it |
| One record has a block or a do-not-contact entry | Merge, then confirm the restriction still applies to the survivor before anything is written to them |
| You are not sure | No. Two records cost you context; a wrong merge costs you trust |
Stopping them coming back#
Most duplicates are created by the same few habits. Imports that map an address column to a name field produce them in bulk, so a twenty-row trial import before the full one pays for itself. Records created by hand during a call produce them when the number is not captured as an identity — a contact created from a call now carries its phone key from the start, specifically because most of a sample of contacts created earlier had none and could never be matched to an incoming call.
Companies deserve the same pass occasionally. Several people attach to one organisation, so a duplicated company quietly splits a relationship in two even when every person record is correct — and the split is invisible from either half.
Questions#
Does Connect merge duplicates on its own?
No. It proposes; a person decides. That split is deliberate — a wrong automatic merge combines two people's histories and is not cleanly reversible, which is not a risk worth a saved click.
What happens to the record that does not survive?
Its identities, stages, follow-ups, deals, demos, cases and onboarding are carried across to the survivor. That is the design goal of the merge: nothing from either side is silently dropped.
Will merging affect a block or an unsubscribe?
Check it explicitly on the survivor before anything is written to them. A restriction that mattered on one side still matters afterwards, and this is the one post-merge check with a consequence outside your own records.
Can I merge companies as well as people?
Companies are records in their own right and are worth the same periodic review. A duplicated organisation divides the relationship without either half looking wrong.