An obvious duplicate was not suggested
Duplicate detection proposes; it never decides. It works from the evidence on the records — the identities they hold and the names and organisations written on them — so two records that share no address and no normalised name give it nothing to propose. Recognising a duplicate from context you hold and Connect does not is exactly the case for merging manually.
What the detector is working from#
duplicates in relationship_console compares the record evidence: the Identity keys each Person holds, produced by value_key(kind, value) so that the same address in two spellings is one key, together with the names and company links on the records themselves. A proposal is a ranked suggestion for a human, not an action.
- A shared identity — the same address on both records — is the strongest evidence there is, and two records that share one are proposed.
- Closely matching names on records linked to the same Company are a weaker signal, and are proposed as a suggestion rather than a near-certainty.
- Two records that share no identity, no company and no comparable name have nothing to compare, and no proposal is made.
Why an obvious duplicate is invisible to it#
| The pair | What you know | What the records share |
|---|---|---|
| Personal address and work address | Same human | Nothing — two unrelated identity keys |
| A married or changed surname | Same human | A name that no longer matches, and often a new mailbox |
| Nickname against legal name | Sam is Samantha | Nothing comparable, unless a company link joins them |
| A transliterated name | Two spellings of one name | Different strings; the identity keys differ too |
| Imported list against a live contact | The import is the same person | Frequently nothing, because imports often carry only a company address |
| One number, one address, no overlap | Same human, two channels | No shared key — the classic phone-versus-email split |
In every row the detector is behaving correctly. A tool that merged those pairs on its own would also merge two colleagues who share a surname and an office, and the cost of that mistake is a message sent to the wrong person — see two people were treated as one.
What Connect completed, and what it did not#
Connect completed the comparison and found no evidence worth putting in front of you. Both records are intact and correct in themselves: each holds its own identities, stage, follow-ups, deals and history, and everything already done under either of them stands.
What it did not complete is any inference from outside the records. It does not read a signature block to conclude two mailboxes are one person, and it does not merge on similarity alone. Until somebody merges, the two histories stay apart, and a reply grounded in one of them will not know what the other holds.
Merging it yourself#
Open both records and satisfy yourself they are one human. Check the identities, the company and the last few conversations.
Result This is the whole decision. Everything after it is mechanical.
Decide which record survives. Prefer the one with the richer history and the identity the person actually uses now.
Result The surviving record is where the merged relationship lives afterwards.
Run the merge from the relationship screen.
Result Identities, lifecycle stages, follow-ups, deals, demos, cases and onboarding from both sides are preserved on the survivor. Nothing is discarded to make the join tidy.
Read the merged timeline once, end to end.
Result Two histories interleaved in time order is the proof the merge did what you wanted — and the moment to spot a third record you had not noticed.
Stopping the next one#
- Add identities as you learn them
- The moment you know a personal mobile belongs to a customer, add it. An identity added today is a duplicate that never happens.
- Link people to companies
- A company link turns an unmatchable name pair into a comparable one, which is the cheapest way to make future proposals better.
- Import against existing records
- An import that carries only a company address will collide with itself. Import with the address the person actually corresponds from where you have it.
- Record the reason in memory
- If a pair is *not* a duplicate — two brothers at one firm, say — write that down against the records so the next person to look does not merge them.
Questions#
Can Connect merge duplicates automatically if I turn something on?
No. merge_people is a human decision by design. Merging is close to irreversible and its failure mode is contacting the wrong human, so it is not delegated to autonomy at any mode.
Will merging lose the smaller record's follow-ups or deals?
No. The merge preserves identities, stages, follow-ups, deals, demos, cases and onboarding from both sides. What you lose is the second record as a separate row, not the work recorded against it.
Two records share an address but were never proposed — why?
Check that the address is actually an Identity on both rather than text in a note or a signature. Only identity rows are compared, which is also why attaching an address is the fix that makes the pair visible.