# The WhatsApp message attached to the wrong person

A WhatsApp thread is showing against the wrong contact. There are only two shapes of this problem — one human holding two records, or one record holding two humans — and they have opposite repairs. Matching is by sending number alone, so the fix is always to correct the identity, never to move an individual message.

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

## What the symptom looks like

A conversation appears under a name that is not the person writing. It shows on that contact's timeline, their history is what the reply was grounded in, and anything Connect learned from the exchange has been attached to them. Sometimes the giveaway is a reply that references something the sender never said.

The related and more common variant: a customer you know well appears as a brand-new contact with no history, because they wrote from a number that was not on their record.

## What it means

An Identity is one address on one channel and belongs to exactly one Person. Resolution takes the sending number, normalised, and looks for the Identity that matches. Nothing else is treated as an identifier — a WhatsApp profile name may become a provisional display name on a new record, but it never joins two records together.

That conservatism is deliberate and it produces both symptoms above. Connect will not merge two people because their names look alike, which is why a second number arrives as a second contact. And it will not split a record on its own, which is why a reassigned number keeps landing on its previous owner until somebody says otherwise.

## Causes, in the order worth checking

1. **The person wrote from a second number** — a personal mobile, a colleague's handset, a new SIM. A new contact, no history, everything else correct.
2. **A number was reassigned** by a telecom operator to somebody else, and it is still on its old owner's record.
3. **A shared handset** — a reception desk, a family business — where several humans send from one number.
4. **A number was typed onto the wrong record** during an import or a manual edit, which is the one case where the data was wrong before any message arrived.
5. **Two records for the same human already existed**, and the message correctly matched the one you were not looking at.
6. **The thread is merely *labelled* oddly.** On a QR-linked number the handset's own address book supplies thread names, so a conversation can be titled the way the business saved that person on the phone. That is a display name, not a resolution: the Person underneath is still the one the number matched.

The last one is worth separating from the rest before anything is repaired. If the thread title disagrees with the contact but the timeline, the history and the grounding are all right, nothing is mis-resolved and merging two records would create the fault you were trying to fix.

## What Connect did complete

- It received and stored the message; nothing is lost and nothing needs re-sending.
- It resolved the sender against the identities the workspace actually holds, and it applied the correct rule to the data it had.
- It wrote the exchange to a timeline and, if the channel was answering, sent a reply grounded in that record's history.
- It recorded what it did, so the wrong attachment has a visible origin rather than being a mystery on a timeline.

## What Connect did not complete

It did not verify that the human behind the number is the human on the record, because nothing in a WhatsApp message makes that possible. It cannot: a number is the only identifier the channel offers, and a reassigned number carries no signal that it changed hands.

> **Careful** Until the identity is corrected, a reply on that thread is grounded in the wrong person's history. On a reassigned number that means details about one customer can be repeated to a stranger, which is the reason to treat this as urgent rather than untidy.

## What you can do

1. Decide which shape it is: one human with two records, or one record with two humans.
   - Result: The repairs are opposite, and doing the wrong one makes the problem worse.
2. For one human, two records — merge them from the relationship screen.
   - Result: Identities, conversations and memory move onto the surviving record, and the merge is recorded so the joined history is explicable later.
3. For one record, two humans — detach the number from the Person it no longer belongs to before anything else.
   - Result: Later messages from it stop landing on the wrong history. What was already written stays where it was until it is moved deliberately.

Corrections are made against the record rather than against a message, and the engine reads the corrected state the next time it picks up work — so a fix changes future behaviour, not just the view.

## What an administrator can do

Review what the wrong record learned. Memory written at the contact tier during the mistaken exchange belongs to the wrong person and should be removed; the memory viewer shows what is held at every tier and lets it be forgotten. Check any follow-up, opportunity or case created from the conversation, and check whether a suppression was recorded against the wrong contact — a stop attached to the wrong person is the version of this that goes unnoticed for months.

## When to escalate

Escalate when a merge does not produce one coherent history, or when the same number keeps re-attaching to a record after being detached — neither is expected behaviour. Escalate immediately, on any path, if a customer's details were disclosed to a stranger through a reassigned number: that is a data question rather than a tidiness one.

## Questions

### Can I move one message to another contact?

The correction to make is on the identity, not the message. Moving a single message would leave the next one landing in the same wrong place.

### Does merging lose anything?

No. Identities, conversations and memory move onto the surviving record, and the merge itself is recorded so the combined history can be explained later.

### Why does Connect not use the profile name to match people?

Because people set profile names to nicknames, businesses and emoji, and matching on them would join records that are not the same human. A wrong merge is much harder to undo than a duplicate.

## Related

- [Recognising who sent a WhatsApp message](https://connectbyjbrh.com/docs/whatsapp/person-resolution/)
- [WhatsApp in Connect](https://connectbyjbrh.com/docs/whatsapp/)
- [Relationships in Connect](https://connectbyjbrh.com/docs/relationships/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)
- [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/)
- [Why the machine proposes a merge and a person disposes](https://connectbyjbrh.com/research/one-person-many-channels/)
- [Telling a new prospect from an existing customer](https://connectbyjbrh.com/research/prospect-identity-resolution/)

## What this page is based on

- `backend/app/whatsapp.py` — `_link_person`, `_link_contact`, `_apply_state_sync`, `normalise_number`
- `backend/app/identity.py`, `relationship_console.py` — resolution and merges
- `docs-source/sources/GENERAL.md` §6 — memory tiers and the memory viewer
- Connect capability registry (docs-source/facts.py) — `cross_channel_identity`, `duplicate_merge`