skip to Main Content

Important Update for Service Cloud – New Email to Case Behavior

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.

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.

What’s Changing?

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.

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’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.

Gotchas

First, any replies to emails sent prior to Summer 20 (that’s July 2020) will create a new case and won’t match up. At this point, that is over one year ago, so if a customer is replying to an email that’s that old, it’s hopefully going to be a one-off. This really shouldn’t be an issue anymore – but it’s something to keep in mind when that one customer does decide to reply.

Finally, there is a bit of a weird bullet here: “Make sure the emails sent to Salesforce contain the correct required Threading headers for matching.” This is a bit of a tough one as we can’t control what our customers include in the emails they send to us and you might not know if you have major issues until you’re live. So once you’re live, it’s worth keeping a lookout for strange behavior from certain customers – and this is probably the problem. On something like this, you probably want to leverage your IT team to analyze the incoming headers and see what’s going on.

Also, just to mention it – this applies to all Service Cloud instances – whether you are in Classic or Lightning.

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.

Melissa VanDyke

Melissa is the Director of Customer Success Solutions at Gears and is a former Salesforce MVP and 4x presenter at Dreamforce. She is passionate about helping ambitious admins further their careers through being an agent of change, improving process, and team collaboration. She consults on the premise that change, not technology, is typically the hurdle to any implementation or optimization and spends time understanding how her customers approach strategies for change and adoption to ensure Gears’ offerings are aligned to help them be successful!

This Post Has 4 Comments

    1. Great catch, and thank you. We just updated this. We had this in our first blog and then reverted back to the original date by accident here!

    1. Yes – anything using the “reference ID” for the matching logic on replies. If you built something matching in another way, you are fine – but if you’re leveraging the reference ID field in any way, this will need to be adjusted to the new method.

Leave a Reply

Your email address will not be published.

Back To Top