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 in to the new threading behavior.
Scenario: Custom Email Messages
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 email includes an email template which includes the Case Thread Id in order for responses to link back to the original case. (The flow does not create an email message record).
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 subject line includes thread id 123.
Day 5: Opt In to Disable Ref ID and Transition to New Email Threading Behavior
Day 10: The client responds to the reminder email with the information requested.
Result
Rather than linking to the original case, Email-to-Case create a new case.
Why?
(1) The thread id included in the response email, is no longer leveraged.
(2) The email header message identifier references find no match existing email messages. Therefore, no case is found.
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.
- Populate the Thread Id: Create a custom field on the case to store the thread id (such as thread_id__c). Populate the generated thread id (Email-to-Flow has you covered Retrieve the Case Thread Id) on the case (at a minimum for all cases you expect responses, such as open cases). Leverage the power of Email-To-Flow to create an overlapping Email-to-Case process which attempts to match on Thread Id (if it exists on the email), then attempts to match on the email header.
- Pros: Matching can occur on the original thread id logic while slowly moving towards the new threading behavior without causing duplicate cases.
- Cons: Transition planning is required to populate the thread id on the case. Additional planning is required to convert from the standard Email-to-Case to Email-To-Flow.
- 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. You can even decide if the thread id will exist in the subject, email body, or even the email header ( 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.
- Populate missing Email Message record with Message Identifier: If the data exists, recreate the missing email message records and populate these records with the correct message identifier. Most likely, this will prove near impossible. However, if you can early enough, you can modify your existing processing to ensure email message records are properly getting created. If this can be implemented so that all outstanding emails do indeed have email message records (before you Opt In to Disable Ref ID and Transition to New Email Threading Behavior), you can confidently transition to the new threading behavior with no concerns.
- Pros: Your email-to-case process can remain standard Salesforce as all the data components required for Email-to-Case will be in place.
- Cons: Additional planning and enhancements are required to convert existing custom code to a process that generated email message records.
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 2).