If your organization uses Email-to-Case, this post is for you! Almost one year ago, Salesforce announced major changes to their Email-to-Case threading behavior, and we covered this in detail back in our Spring ‘21 Release Notes.
So, why are we blogging about this now? While this new behavior wont be enforced until Summer 22 we recommend taking the time to start your planning and testing sooner than later because these things sneak up on you! There is nothing worse than doing a change like this under the gun, so let’s recap what’s changing and what action you can start to take now! Let’s recap what’s changing and what action you need to take over the next few months to get ready for this change.
Salesforce is leveraging header information from the email to figure out the matching and which Case it relates to. Most customers wouldn’t mess with an email header (or wouldn’t know how to) so this should reduce duplicates, help keep data clean and generally streamline the process. For full details on the change, check out this Salesforce knowledge FAQ article.
It’s important to note that this is a mandatory change. For new customers provisioned after Winter ‘21, the new threading is turned on automatically. For existing customers, you do need to take some action.
What is Email Threading?
Email threading consolidates all the communications, replies, and forwards pertaining to an initial email – or for Service cloud, it’s everything related to a Case. For the longest time, Salesforce used a reference ID to determine which Case an email reply should be linked to.
The reference IDs need to be stored within the email body or header and they are long, and a bit ugly, but simple enough. Where you run into trouble is when you occasionally have customers that for some reason delete this info. This causes confusion in the system and most times a new (duplicate) Case is created because the system thinks it’s a net-new issue.
If you’re using standard Email-to-Case
If you are not using a custom email service, the biggest thing to make sure of when enabling the new thread functionality is to test fully before enabling it in production. You want to pay particular attention to in-flight case threads to make sure you understand the behavior here.
If you’re using a custom email service
We have many customers that have chosen to build a custom email service using Apex to tailor their matching logic. Another big benefit of a custom email service is parsing information out of the body of the email, from the sender, etc. to pre-populate the Case with information and maybe even intelligently route the case.
Existing custom email services using the old method (getCaseIdFromEmailThreadId) will need to be updated with the new method (getCaseIdFromEmailHeaders). In short, you’ll want to search all of your code for anything using the thread ID for matching.
If you want a second set of eyes on your instance to make sure you’re ready for this change, we can help! Fill out the form below and we’ll be in touch to set up a time to chat.