Microsoft Graph Webhook — conversationId changes when external party replies, breaking email thread grouping for case management

---

Title: Microsoft Graph Webhook — conversationId changes when external party replies, breaking email thread grouping for case management

---

Background / Context

We are building a case management system where we listen to a client's Outlook mailbox via Microsoft Graph change notifications (webhooks). When a new email arrives, we create or update a Case based on the email thread. The goal is: all emails belonging to the same conversation should be linked to the same Case.

Current Behavior — The Problem

When an external party (e.g. someone on Gmail, Yahoo, or another org's Exchange) replies to an existing thread, Microsoft Graph assigns a new conversationId to that reply, even though it is clearly part of the same conversation (the RFC 2822 References and In-Reply-To headers correctly point back to the original message).

Similarly, we have observed that internetMessageId can differ per message since each MTA stamps its own Message-ID, so it cannot be used as a thread grouping key — only as a per-message dedup key.

Example flow:

1. External sender emails client internetMessageId : [******@externalsender.com] conversationId : AAQkADFmM... (Exchange assigns this)
2. Client replies from Outlook internetMessageId : [******@clientdomain.com] conversationId : AAQkADFmM... (SAME)
3. External party replies back from Gmail internetMessageId : [@gmail.com] conversationId : AAQkABBBB... (DIFFERENT — new Exchange thread) In-Reply-To : [@externalsender.com] (correct RFC threading) References : [******@externalsender.com] (correct RFC threading)

At step 3, Graph creates a brand new conversationId, so our system creates a new Case instead of linking it to the existing one.

Questions

1. Why does Exchange/Graph assign a new conversationId for external replies?

Is this by design? Our understanding is that conversationId in Exchange is derived from the Thread-Index MAPI property, which is a Microsoft-proprietary header. External senders on Gmail etc. do not send Thread-Index, so Exchange cannot continue the same thread. Is this the correct explanation?

1. Is Thread-Index the sole determinant of conversationId?

Does Exchange fall back to References or In-Reply-To (standard RFC 2822 headers) at all when Thread-Index is absent? Or is conversationId purely derived from Thread-Index?

1. Is there any Graph API field that provides stable thread identity across external replies?

We are already fetching internetMessageHeaders and parsing References and In-Reply-To ourselves to stitch threads. Is there a first-class Graph API field we are missing that would give us a stable cross-sender thread identifier — something like a canonical thread root ID?

1. Can conversationId ever be the same across two separate Exchange mailboxes?

If the same email arrives in two monitored mailboxes, will both copies carry the same conversationId, or is it mailbox-scoped?

1. Is internetMessageId guaranteed stable once delivered to the mailbox?

We understand each sender's MTA stamps its own Message-ID. But once a message is delivered to Exchange and visible via Graph, is the internetMessageId field guaranteed to never change — even across folder moves, mailbox migrations, or retention policy actions?

1. What is the recommended Microsoft Graph approach for grouping emails into threads for a case management or ticketing system?

Is the intended pattern to use conversationId only for same-org threads and fall back to RFC headers for cross-org? Use conversationId as a starting point but maintain a merge table when IDs drift? Or something else entirely?

What We Have Tried

Using conversationId as the Case grouping key — breaks on external replies.

Using internetMessageId as a dedup key per message — works for deduplication but does not group threads.

Parsing References and In-Reply-To from internetMessageHeaders and matching against previously seen internetMessageId values stored per Case — works but feels like we are re-implementing what Exchange should already know.

Normalized subject plus participant overlap as a fuzzy fallback — catches stripped-header forwards but risks false positives.

Environment

Microsoft Graph SDK for Java v6 Spring Boot webhook listener Subscribing to /users/{id}/messages change notifications Permissions: Mail.Read application permission Single client Outlook mailbox, not our own tenant

What We Are Looking For

Confirmation of the root cause, whether there is a stable Graph API field we are missing, and what the recommended pattern is for building reliable email thread grouping on top of Microsoft Graph webhooks.

Claude is AI and can make mistakes. Please doHere's the plain copy-paste version:

---

Title: Microsoft Graph Webhook — conversationId changes when external party replies, breaking email thread grouping for case management

---

Background / Context

We are building a case management system where we listen to a client's Outlook mailbox via Microsoft Graph change notifications (webhooks). When a new email arrives, we create or update a Case based on the email thread. The goal is: all emails belonging to the same conversation should be linked to the same Case.

Current Behavior — The Problem

When an external party (e.g. someone on Gmail, Yahoo, or another org's Exchange) replies to an existing thread, Microsoft Graph assigns a new conversationId to that reply, even though it is clearly part of the same conversation (the RFC 2822 References and In-Reply-To headers correctly point back to the original message).

Similarly, we have observed that internetMessageId can differ per message since each MTA stamps its own Message-ID, so it cannot be used as a thread grouping key — only as a per-message dedup key.

Example flow:

1. External sender emails client internetMessageId : [******@externalsender.com] conversationId : AAQkADFmM... (Exchange assigns this)
2. Client replies from Outlook internetMessageId : [******@clientdomain.com] conversationId : AAQkADFmM... (SAME)
3. External party replies back from Gmail internetMessageId : [@gmail.com] conversationId : AAQkABBBB... (DIFFERENT — new Exchange thread) In-Reply-To : [@externalsender.com] (correct RFC threading) References : [******@externalsender.com] (correct RFC threading)

At step 3, Graph creates a brand new conversationId, so our system creates a new Case instead of linking it to the existing one.

Questions

1. Why does Exchange/Graph assign a new conversationId for external replies?

Is this by design? Our understanding is that conversationId in Exchange is derived from the Thread-Index MAPI property, which is a Microsoft-proprietary header. External senders on Gmail etc. do not send Thread-Index, so Exchange cannot continue the same thread. Is this the correct explanation?

1. Is Thread-Index the sole determinant of conversationId?

Does Exchange fall back to References or In-Reply-To (standard RFC 2822 headers) at all when Thread-Index is absent? Or is conversationId purely derived from Thread-Index?

1. Is there any Graph API field that provides stable thread identity across external replies?

We are already fetching internetMessageHeaders and parsing References and In-Reply-To ourselves to stitch threads. Is there a first-class Graph API field we are missing that would give us a stable cross-sender thread identifier — something like a canonical thread root ID?

1. Can conversationId ever be the same across two separate Exchange mailboxes?

If the same email arrives in two monitored mailboxes, will both copies carry the same conversationId, or is it mailbox-scoped?

1. Is internetMessageId guaranteed stable once delivered to the mailbox?

We understand each sender's MTA stamps its own Message-ID. But once a message is delivered to Exchange and visible via Graph, is the internetMessageId field guaranteed to never change — even across folder moves, mailbox migrations, or retention policy actions?

1. What is the recommended Microsoft Graph approach for grouping emails into threads for a case management or ticketing system?

Is the intended pattern to use conversationId only for same-org threads and fall back to RFC headers for cross-org? Use conversationId as a starting point but maintain a merge table when IDs drift? Or something else entirely?

What We Have Tried

Using conversationId as the Case grouping key — breaks on external replies.

Using internetMessageId as a dedup key per message — works for deduplication but does not group threads.

Parsing References and In-Reply-To from internetMessageHeaders and matching against previously seen internetMessageId values stored per Case — works but feels like we are re-implementing what Exchange should already know.

Normalized subject plus participant overlap as a fuzzy fallback — catches stripped-header forwards but risks false positives.

Environment

Microsoft Graph SDK for Java v6 Spring Boot webhook listener Subscribing to /users/{id}/messages change notifications Permissions: Mail.Read application permission Single client Outlook mailbox, not our own tenant

What We Are Looking For

Confirmation of the root cause, whether there is a stable Graph API field we are missing, and what the recommended pattern is for building reliable email thread grouping on top of Microsoft Graph webhooks.