The same conversation appears twice

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#

Related#

• Conversation threads
• Duplicate detection
• Merging two records
• What a merge preserves
• Resolving a sender to a person
• Customer 360
• Creating a conversation thread, end to end