# The same conversation appears twice

Threading follows the reference headers a sending client writes, and some clients and mailing lists rewrite them — which splits one exchange into two conversations. Connect does not stitch threads back together; it merges the *people*, so Customer 360 and the timeline show one continuous history even where the mail itself arrived in two pieces.

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

## What the symptom looks like

- Two conversations with the same subject, or nearly the same subject, from the same person.
- A reply that opened a new conversation instead of continuing the old one.
- The same human appearing twice in relationships, usually with two addresses.
- A reply drafted against the newer conversation with no knowledge of what was said in the older one.

The last of those is the one that costs something. A split conversation is untidy; a split *person* means the reply is written without half the history, and that is visible to the customer.

## Why threads split

1. **The reference headers were rewritten.** Some mailing lists, ticketing systems and mobile clients rebuild the headers that link a reply to its parent. Nothing downstream can recover the link that was removed.
2. **The subject changed enough.** A reply sent as a fresh message rather than as a reply carries no reference to what came before, whatever the subject says.
3. **The person wrote from a second address.** Their personal address and their work address are two identities, so the second exchange attaches to a second identity — correctly, until somebody says they are the same human.
4. **A forwarded conversation re-entered the mailbox.** A forward is a new message from a different sender, and treating it as a continuation would attribute somebody else's words to the original correspondent.

Threading is inherited from the mail itself rather than guessed. That is a deliberate limit: joining two conversations on a resemblance is how one customer's message ends up in another customer's thread, which is a worse failure than a duplicate.

## The repair, stage by stage

1. Trigger — somebody notices the same exchange in two conversations, or the same person listed twice.
2. External event — the split happened in the sender's client, before the message ever reached the mailbox.
3. Authentication and workspace resolution — the threads, identities and people all belong to one workspace and are read inside it.
4. Ingest — no re-fetch is needed; both halves are already canonical records.
5. Canonical record — two `threads` rows exist, each complete and each correct about what it contains.
6. Classification — decide whether the duplication is at the thread level, the identity level or the person level; the remedy differs.
7. Knowledge, memory and rules — memory set against one contact does not apply to a second person record, which is one practical cost of leaving a duplicate in place.
8. Autonomy and approval — merging people is a record change a person makes; it is not something the engine does on a resemblance.
9. Action — merge the duplicate people, attaching both identities to one person.
10. Result — one person, two identities, both conversations attributed to the same human.
11. Relationship, timeline and memory — Customer 360 and the timeline show the whole exchange in order, whichever thread each message arrived on.
12. Audit, usage and Needs You — the merge is recorded, because it is a decision that changes what future replies are written from.

## What Connect did complete

- Both messages were fetched, bridged and threaded exactly as their headers described.
- Each conversation is complete and internally correct; nothing was dropped in either.
- Each address was resolved to an identity, and each identity to a person.
- The timeline holds every message in order, which is what makes the whole story recoverable after a merge.

## What Connect did not complete

- It did not join the two threads. Thread identity comes from the mail, and Connect does not rewrite it on a guess.
- It did not assume the two addresses belong to one human. That assumption, made automatically, mixes people who share a surname or a shared mailbox.
- It did not apply memory set against one contact to the other, so guidance you gave on the first conversation had no effect on the second.
- It did not warn you at draft time that half the history was somewhere else — the second conversation looks complete on its own.

## What you can do, and when to escalate

1. Decide whether it is a thread duplicate or a person duplicate.
   - Result: A thread duplicate with one person behind it is cosmetic; two person records are the version that affects replies.
2. Merge the duplicate people, keeping both identities on the surviving record.
   - Result: Customer 360 and the timeline show one history, and future replies are written from all of it.
3. Re-set any memory or guidance that was attached to the record you merged away.
   - Result: Memory follows the contact, so check the surviving person still carries what you told Connect.
4. Leave the two conversations as they are.
   - Result: They remain accurate about what was actually sent, which is what an audit needs.

An administrator can review merge safety before a large clean-up — a merge is easy to perform and awkward to reverse, so the checks that exist around it are worth reading first. Escalate when the same person keeps splitting after a merge, which usually means a sending system on their side is rewriting headers on every message rather than anything in the workspace.

## Questions

### Can I merge two conversations into one?

No, and deliberately so: a thread records what was actually exchanged, and rewriting that to look tidier would damage the record an audit relies on. Merge the people instead — the timeline then reads as one conversation.

### Will Connect reply on the wrong thread?

It replies on the thread the customer wrote on, which is the right behaviour. After a merge it writes with the whole person's history behind it, even though the messages live on two conversations.

### Does a duplicate person affect anything besides tidiness?

Yes. Memory, guidance, follow-ups and lifecycle stage all attach to a person, so a duplicate splits the things that shape a reply. That is the reason to merge rather than to ignore it.

## Related

- [Conversation threads](https://connectbyjbrh.com/docs/email/threads/)
- [Duplicate detection](https://connectbyjbrh.com/docs/relationships/duplicates/)
- [Merging two records](https://connectbyjbrh.com/docs/relationships/merging/)
- [What a merge preserves](https://connectbyjbrh.com/docs/relationships/merge-safety/)
- [Resolving a sender to a person](https://connectbyjbrh.com/docs/email/contact-resolution/)
- [Customer 360](https://connectbyjbrh.com/docs/relationships/customer-360/)
- [Creating a conversation thread, end to end](https://connectbyjbrh.com/docs/workflows/thread-creation/)

## What this page is based on

- Connect source pack — channels, §1: canonical threads, messages and contacts, and the bridge that creates them (`docs-source/sources/CHANNELS.md`)
- Connect source pack — relationships: identities, people, duplicates and merging, Customer 360 (`docs-source/sources/GENERAL.md` §4)
- Connect capability registry (`docs-source/facts.py`) — `duplicate_merge`, `cross_channel_identity`, `customer_360`