# Duplicate detection

`duplicates` proposes pairs of records that look like the same human and stops there. It is a suggestion queue, not a background job that tidies your data: `merge_people` runs only when a person accepts, because folding two histories into one is a decision with consequences no confidence score should be trusted to make on its own.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/data
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/relationships/duplicates/

## How a workspace grows duplicates

Duplicates are not a sign of a fault. They are the ordinary result of recognising addresses exactly rather than guessing at humans, and every workspace that runs more than one channel accumulates them.

1. Somebody rings from a number that is not yet an identity, and a person record is created for that number.
2. The same human writes from a work address that already resolves elsewhere, so a second record carries the email history.
3. An import brings in a list where the same human appears under a different spelling.
4. A colleague is added by hand while a record for them already exists under a personal address.

Each of those is the right behaviour at the moment it happens — the alternative is joining strangers on a resemblance. What follows is a proposal, and the proposal is where the ambiguity is meant to surface.

## What a proposal is, and is not

| It is | It is not |
|---|---|
| A pair of records worth a person's attention | A verdict that they are the same human |
| Reversible by ignoring it | Reversible after acceptance — a merge has no clean undo |
| An input to a decision | A queue that drains itself while nobody watches |
| Bounded and shown with both sides | A bulk operation you can run over a whole list unread |

The exact signals a proposal is built from are not published here, and that is deliberate: a documented scoring rule invites tuning against the score rather than reading the records. What matters to you is what to check, which is the same list whatever produced the proposal.

## What to check before accepting

1. Open both records side by side and read the identities.
   - Result: Shared or complementary identities — a work address on one, a mobile on the other — is the strongest ordinary evidence.
2. Read the most recent conversation on each.
   - Result: Two records that talk about the same order, the same site visit or the same quote are usually one human; two people at one customer are not.
3. Check the company link and the lifecycle stage on both.
   - Result: A shared employer is context rather than proof. Different stages are not a reason to refuse — the merge carries stages from both sides.
4. Check what is open on each: cases, demos, opportunities, follow-ups.
   - Result: Nothing is lost by merging, but a person should know what the surviving record will be carrying afterwards.

> **Careful** Two people at one company with similar names are the classic false positive, and accepting it is expensive: the merged record blends two humans' histories and the fix is manual. If you are unsure, leave the proposal alone — an unmerged pair costs far less than a wrong merge.

## When nothing is proposed

The other failure is silence: two records that plainly describe one human and no proposal in sight. Because detection is a suggestion rather than a guarantee, a merge does not depend on it — a person can merge two records they have found themselves, which is the ordinary answer to this. [No duplicate was suggested](/docs/troubleshooting/duplicate-not-detected/) goes through the causes.

The Data grid's `people` sheet is the practical tool for finding them at scale: sort by name, group, and read the pairs. Its duplicates view is over the same records, and every action taken there goes through the service that owns them rather than writing rows directly.

## Questions

### Will Connect merge records on its own overnight?

No. Detection proposes; `merge_people` is a human decision. That boundary is the point of the feature — an automatic join is the one change in this area that cannot be safely undone, so it is not automated.

### Can the Assistant merge two people for me?

The Assistant's rights are narrower than a person's, and it can read relationships, cases, follow-ups and opportunities. Treat a merge the way you would a do-not-contact change: something a person decides with both records in front of them.

### Does ignoring a proposal make it come back?

Ignoring costs nothing — the records stay separate and both keep working. The practical downside is the one the pair already has: each channel answers with half the history, which is what [customer 360](/docs/relationships/customer-360/) shows you plainly when you open either side.

## Related

- [Merging two records](https://connectbyjbrh.com/docs/relationships/merging/)
- [What a merge preserves](https://connectbyjbrh.com/docs/relationships/merge-safety/)
- [One person across phone, email and WhatsApp](https://connectbyjbrh.com/docs/relationships/cross-channel-identity/)
- [An obvious duplicate was not suggested](https://connectbyjbrh.com/docs/troubleshooting/duplicate-not-detected/)
- [Merging duplicate people, end to end](https://connectbyjbrh.com/docs/workflows/duplicate-merge/)
- [Files and data in Connect](https://connectbyjbrh.com/docs/files-data/)

## What this page is based on

- `docs-source/sources/CHANNELS.md` §5 — `duplicates` proposes, `merge_people` is a human decision
- `docs-source/sources/GENERAL.md` §8 and §9 — Assistant rights and the Data grid
- Connect capability registry (docs-source/facts.py)