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
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; itsIn-Reply-Toreferences<[email protected]>(the operator's message), whoseReferenceschain traces to<[email protected]>. EasyCRM matches the reply'sIn-Reply-Toagainst a knownInternetMessageIdon the same mailbox and appends the message to the existingConversation.
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.