Email-to-Case Threading Limitations & Considerations

General Considerations

• If you have more than one email routing address, ask your customers to email only one address at a time, and not to include more than one routing address in their email thread. Sending an email to multiple Email-to-Case routing addresses causes unexpected results, and this use case isn’t supported.
• When two cases are merged, all additional incoming emails are associated with the parent case even if they pertain to the newly merged child case. The service rep performing the merge decides which case becomes the parent case.

Ref ID Threading

If Lightning threading or email header-based threading isn’t enabled in your org:

• Responses to case email alerts aren’t added to the case feed.
• Incoming email responses that are missing a Ref ID—often caused by the customer modifying the email subject—aren’t added to an existing case. Instead, a new case is created.
• Spaces and new lines may be added before and after the Ref ID.

Email Header-Based Threading

• In Winter ’23 and later, email alerts contain the information needed for threading. When you enable email header-based threading, Email-to-Case adds replies to the alert to the case feed. In a pre-Winter ’23 org, if a case email alert was sent before email header-based threading was enabled, incoming responses to the alert aren’t added.
• If you use an email relay that changes the Salesforce-generated Message-ID, the relay must also move the original Message-ID into the References header to maintain the threaded conversation.
• If you use an email exchange, custom mail transfer agent (MTA), or third-party client, it must maintain the References and In-Reply-To header values. Removing or modifying them can cause new cases to be created.

Lightning Threading

• Caution your customers against modifying the email subject when replying. Depending on the email client, changing the subject can remove email threading tokens and cause new cases to be created.
• Avoid using multiple threading tokens in an email, since that can lead to uncertain behavior. If you’re trying to move an email to another case, use the Move Email action.
• Incoming responses to pre-Summer ’20 emails that were sent from the case feed email composer aren’t added to the case.
• When Lighting threading is in use, emails sent from a case are associated with that case. If a rep wants to reply but create a new case, they must compose a new email, copy in the reply email body, and send the new email to the support address.
• If your org ID changes—for example, if you refresh a sandbox—the Case Thread Token associated with the original org ID is no longer valid.

Threading in Salesforce Classic

If you’re using Salesforce Classic and you switch from Ref ID threading to Lightning threading, here’s what to expect.

• Threading tokens aren’t added automatically to emails sent in Salesforce Classic. To insert a threading token into an email, use an email template that includes the {{{Case.Thread_Token}}} merge field.
• If a token isn’t found in an incoming email, Email-to-Case defaults to header-based threading.
• The Ref ID merge field in email templates, Case.Thread_Id, no longer gets evaluated, while the threading token merge field, Case.Thread_Token, is still evaluated correctly.

Overall, changes to the Salesforce Classic user experience are minimal. You can switch to Lightning Experience, use Salesforce Classic email templates with {{{Case.Thread_Token}}}, or proceed with only header-based threading.

Alternatives to Lightning Threading

The Messaging.InboundEmailHandler Apex interface lets you further customize email matching by creating your own custom Apex email service, but we don’t recommend this approach. Lightning threading is the newest and most secure option and includes email header-based threading.