Group emails belonging to the same exchange into a single conversation

Related email messages on the same mailbox are grouped into one `Conversation`, using RFC 5322 threading headers first, then the provider's own thread id, then a normalized subject and participant window as a last resort.

When this happens: A message related to an earlier one is captured.

Step by step

  1. 1

    Open the conversation and sees both exchanges as one continuous thread.

    Captures the customer's first email (Order #4821 delayed?) as Message 1 of a new Conversation; its . Captures the customer's reply to the operator's answer; its In-Reply-To references <[email protected]> (the operator's message), whose References chain traces to <[email protected]>. EasyCRM matches the reply's In-Reply-To against a known InternetMessageId on the same mailbox and appends the message to the existing Conversation.

Other paths

Missing rfc 5322 headers — provider thread id

The provider strips threading headers. Falls back to comparing the provider's own thread id (Gmail threadId / Graph conversationId) against Conversation.ExternalThreadId.

No headers and no provider thread id — subject/participant fallback

Falls back to a normalized-subject and overlapping-participant match against the most recent open conversation on the same mailbox, only within the 3-day grouping window; outside the window or with no participant overlap, a new conversation starts instead.

If something goes wrong

Thread resolves to an already-resolved conversation

The matched conversation is Resolved and outside the reopen window (FR-14). A new conversation starts per FR-14's rules — this is not a grouping error.

Good to know

  • Precedence is RFC 5322 headers, then provider thread id, then subject/participants fallback.
  • The fallback never merges across mailboxes and never exceeds the grouping window.
  • The personal-mailbox sync path (FR-09) threads only by provider thread id; this is the first path to also group by Message-ID/In-Reply-To/References.