# Two people were treated as one

Almost always one address is attached to the wrong Person, or a merge joined two records that were not the same human. Connect did not guess: it followed an Identity row somebody or something created. Fix the identity first, then work through what the confusion already produced — replies, follow-ups, stages and deals do not unwind themselves.

- **Status:** Available
- **Audience:** both
- **In the app:** #/relationships, #/companies, #/timeline
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/troubleshooting/wrong-person-matched/

## What it looks like

- A reply greets the wrong name, or refers to an order that belongs to someone else.
- One timeline holds two people's conversations, and reading it top to bottom makes no sense.
- A follow-up was raised for a person who never asked for it.
- Two colleagues at the same company have collapsed into one record with both job titles.

The symptom is a relationship problem wearing a conversation problem's clothes. Nothing is wrong with the channel: the mail arrived, the call connected, the reply sent. The record underneath is wrong, so everything grounded in it inherits the error.

## What it means

Connect resolves an arriving address with `value_key(kind, value)` and attaches it to whatever Person owns that key. There is no fuzzy name matching in that path, which is why this failure is nearly always a record that was created rather than a match that was invented.

| Cause | How to recognise it | Fix |
|---|---|---|
| A shared mailbox as an identity | The address is a role — accounts@, info@, orders@ | Detach it from the individual; a shared address belongs to the Company, not a Person |
| A merge that should not have happened | Two names, two job titles, one record | There is no automatic unmerge — rebuild the second Person and move the identities back |
| A recycled phone number | Two unrelated histories, split by a date | Detach the number and attach it to the current holder |
| A family or household number | One number, two first names in the transcripts | Keep the number on one Person and record the other as a separate contact |
| A forwarded thread | The sender is your own colleague, the subject is a customer's | Attach the customer's own address; forwarding does not transfer identity |

## What Connect completed

Everything downstream of the wrong record ran correctly against it, and that is what makes the clean-up larger than the fix. Assume all of this happened:

- The message or call was ingested, canonicalised and attached to the Person the identity pointed at.
- Memory was resolved for that Person, including any contact-tier note or block.
- A reply may have been drafted, approved and sent, with real provider evidence against it.
- A follow-up, a lifecycle stage change or an opportunity may have been created under that Person.
- The decision log recorded each of those as correct, because by the rules in force they were.

## What Connect did not complete

It did not, and will not, separate the two people on its own. Splitting a Person is a judgement about two humans and their consent to be contacted, which is exactly the class of decision that belongs to a person. Nothing is auto-unmerged, no sent message is retracted, and no follow-up is cancelled by the correction itself.

> **Careful** Check for a block before you split. A `block:<channel>` directive that belonged to one of the two people applies to the merged record; after a split it must be re-applied to the right one, or you will contact somebody who asked not to be contacted.

## What you can do

1. Open the person and read the Identities list before changing anything.
   - Result: The offending address is visible with its channel. This tells you whether one identity is misplaced or a whole merge is wrong.
2. Detach the address that does not belong, and attach it to the right Person — creating that Person if they do not exist yet.
   - Result: New arrivals on that address resolve correctly from this moment. Nothing already recorded moves.
3. Walk the timeline and reassign what the confusion produced: open follow-ups, the lifecycle stage, any opportunity, any case.
   - Result: Each record moves through the service that owns it, so the audit trail shows who moved it and when.
4. Write the correction into memory against the correct person.
   - Result: A correction that is only a record change is a fact; a correction written as memory is a lesson, and it is the one that changes future behaviour.

If a message went to the wrong person, treat that as its own item: say so to the recipient. Connect will not send that apology unprompted, because nothing in its evidence says the earlier reply was wrong.

## What an administrator can do, and when to escalate

**Audit the merge history** — The decision log names who ran the merge and when, which usually explains a record nobody remembers creating.
**Review role addresses** — A single query over identities for `info@`, `sales@` and similar addresses finds the rest of this class before a customer does.
**Check the company link** — Two colleagues collapsing into one record often starts as a missing company link. See [a person is not attached to their company](/docs/troubleshooting/company-not-linked/).
**Escalate** — Raise it with support when the same address keeps re-attaching itself after being detached, or when a merge preserved less than it should have — those are defects, not data entry.

## Questions

### Can a merge be undone?

Not as an operation. A merge preserves both sides' identities, stages, follow-ups, deals, demos, cases and onboarding, so nothing is lost, but separating them again is manual: recreate the second Person and move the identities and records back to it.

### Why did Connect attach a shared mailbox to one individual?

Because an address is an address. A role mailbox looks exactly like a personal one at the point of resolution. Detach it and keep it on the Company; the useful signal in a role address is the organisation.

### Does correcting the record fix the replies that already went out?

No. Sent is sent, with the provider's acknowledgement recorded against it. The correction changes what happens next, which is why the timeline walk in step three matters more than the identity fix itself.

## Related

- [Identities](https://connectbyjbrh.com/docs/relationships/identities/)
- [Merging two records](https://connectbyjbrh.com/docs/relationships/merging/)
- [What a merge preserves](https://connectbyjbrh.com/docs/relationships/merge-safety/)
- [Deciding whether two records are one person](https://connectbyjbrh.com/docs/workflows/identity-merge-decision/)
- [A person is not attached to their company](https://connectbyjbrh.com/docs/troubleshooting/company-not-linked/)
- [What Connect remembers about a person](https://connectbyjbrh.com/docs/relationships/person-memory/)

## What this page is based on

- docs-source/sources/CHANNELS.md §5 — identity, duplicates and merge_people
- docs-source/sources/GENERAL.md §3 and §6 — canonical rows and block directives
- Connect capability registry (docs-source/facts.py)