In you want a quick summary of the new threading behavior, that a look at our Thread Id versus Email Header post. In this post, we strongly suggest planning for the new threading behavior, especially if your instance includes custom functionality related to Email-to-Case.
In this Why Plan series, we’ll explore some common problematic scenarios related to flipping the switch to opt into the new threading behavior.
Scenario: Stripped Email Header
In order to provide the best possible support to your client, you have implemented a reminder process. If a case is open more than 10 days waiting for a response, an email is sent to remind the client that the case requires addition information or will be closed. The email is generated and sent via a custom flow. The flow process correctly creates an email message record related to the case and follows the recommendation (Email-To-Flow, Custom Email that Links back to a Case) for generating a message identifier.
The Opt In to Disable Ref ID and Transition to New Email Threading Behavior scenario:
Day 1: A reminder email is generated for the client. The Message Identifier is populated in the email message related to the originating case.
Day 5: Opt In to Disable Ref ID and Transition to New Email Threading Behavior
Day 10: The client (manually or automatically) strips the email header and then responds to the reminder email with the information requested.
Note: There are many reasons an email header can be stripped. This can be an intentional rule setup by an admin in Outlook Defender. Or it could be at the email server level when say the subject line is changed.
Note 2: See Email-to-Case Threading Email Doesn’t Attach Back to the Case (salesforce.com) for Salesforce’s take on the situation.
Result
Rather than linking to the original case, Email-to-Case create a new case.
Why?
(1) The email header no longer includes references the original email.
Options
- Do Nothing: The easiest option is to simply let the scenario occur. Instead of linking to an existing case, a new case will be created. The case can be manually matched and merged with the original case as needed.
- Pros: No additional implementation requirements,
- Cons: Duplicate cases must be identified and merged manually.
- Implement a custom thread id: Once you Opt In to Disable Ref ID and Transition to New Email Threading Behavior, the ability to generate a Salesforce Thread Id and automatically match that thread id is deprecated. However, you can roll your own. Leverage the prebuild Email-to-Flow thread id logic, or create your own generation and matching routines to be implemented with Email-To-Flow.
- Pros: You are in control of your own matching logic and can decided if you want to leverage a redundant process or solely your own thread id. (Email-To-Flow, Custom Email that Links back to a Case).
- Cons: Additional planning is required to convert from the standard Email-to-Case to Email-To-Flow.
- Additional Custom Matching: Based on your business requirements, additional matching can be implemented. For example, If the email header was stripped, but the subject is the same. Match on the existence of an open case containing the same subject for the same email address.
- Pros: You are in control of your own matching logic and can decided if you want to leverage a redundant process or solely your own matching logic.
- Cons: Additional planning is required to convert from the standard Email-to-Case to Email-To-Flow.
Interested in learning more? Check us out on the app exchange at Email-to-Flow or give us a ping.
For other scenarios, check out New Threading Behavior; Why Plan? (Part 1).