Skip to main content

#New Email Threading Behavior0 人正在讨论

New Email Threading Behavior

 **Dec. 19, 2022 UPDATE**

 

Hello Trailblazers!

I'm writing to let you know of a brand new webinar that our team recorded, walking you through all the great new email threading updates we have coming in the Spring '23 release!

 

In this webinar, we review the upcoming Lightning Threading Token (a secure replacement for RefID), how it works with Header-Based threading to provide the most versatility over the use cases you've expressed here, and we even go through a demo of the new features!

 

The webinar can be viewed here: https://sfdc.co/LightningThreadingTokenWebinar

 

Thank you all for continuously sharing your input, questions, and concerns here. We hope you enjoy this content we produced for you, and please continue to post questions here as they arise.

 

cc: @Jacinta Burke @Lochlainn O'Shea

=========================

 

**Sept. 15, 2022 UPDATE**

 

Hello!  Again, I’d like to thank you for your patience on this topic. Since my last update, I have been working tirelessly with the Security team on this topic, and my engineering team to intake the feedback we’re receiving and deliver features our customers are asking for. We’re excited to share that we’ve agreed with the Security team to suspend enforcement of the new threading behavior, meaning Salesforce will no longer force customers to switch to the new email threading behavior by the Summer ’23 release.  

 

How does this decision impact the Disable Ref ID and Transition to New Email Threading Behavior (Release Update)? 

The only change is the removal of the Summer ‘23 enforcement date. If you have not yet enabled the release update, you can still enable it in your Orgs. If you have already enabled the release update, nothing will change in your experience. If you have not yet enabled the release update, you have the opportunity to enable it in the same manner you would prior to this change. We still encourage customers to enable this release update and provide feedback.  

 

What does this mean for RefID moving forward? 

We have been transparent that we want all of our customers to adopt our newer, more secure threading model. RefID does not meet the level of security that Salesforce aims to offer our customers, and we will continue improving email threading. While you are no longer required to move to the new email threading behavior by the previously communicated Summer ’23 release, please expect support for RefID to be removed at a later date - TBD.   

 

What are we doing to make Header-Based threading better? 

We have made a number of improvements to our threading model in the Winter ’23:

  • Added an Outlook-specific Thread-Index identifier, which Microsoft Outlook supplies, to aid in threading
  • Added support for Apex emails to leverage header-based threading
  • Improved header-based threading support for Email Alerts across all Orgs, ensuring a smoother transition for customers

*Safe Harbor* Additionally, we plan to introduce a new Email Thread Token which will be available in Spring ‘23. Email Thread Token is intended to provide the same benefits and functionality as RefID, but will be a securely generated identifier that meets the requirements of our Security team. More information on the Email Thread Token will be available closer to its release this Spring, and we will plan on running a webinar to highlight this new functionality.   

 

Over the coming weeks, we will update our customer-facing documentation to reflect this change and will remove the Summer ’23 enforcement from Orgs. Please bear with us during this time as these changes will not be reflected instantly.   

 

Thank you for all of the feedback! While I’m not responding to every single post, please know that I have heard your messages, and am working to deliver a product we can all be happy with. 

 

cc: @Jacinta Burke @Lochlainn O'Shea

=========================

 

Feb. 8 2022 UPDATE:

We have worked with the Security team to confirm a new enforcement date for Disable RefID and Transition to New Email Threading Behavior, which has now been postponed to Summer '23 (June 2023)!

 

We have updated our help documents below to reflect this new date. 

 

Thank you so much for your patience as we continue to get this solution to where it needs to be 🙏🏾

 

=========================

 

Greetings! I’m Jared Long, the new PM for Service Email (Email-to-Case). First of all, I’d like to thank you for your patience and provide an update on the ‘Disable Ref ID and Transition to New Email Threading Behavior’ release update:    

 

As you probably already know, the enforcement date for Disable Ref ID and Transition to New Email Threading Behavior release update has been postponed to Summer '23.   

 

With the immense customer feedback and widespread impact of changes to the RefID, we fully intend to seek an additional enforcement extension from our security team; however, we’re awaiting that confirmation. Our primary goal is to ensure our customers have a smooth transition to this updated feature, and we simply have not been able to devote the time necessary to address the items our community has raised due to other high-impact priorities that have taken precedence over the last 3 releases.   

 

Our plan remains the same - making email threading more robust by incorporating the feedback we have received to date. Here’s what we’ve done so far and what we’re working on:

  • Enforcement of ‘Disable Ref ID and Transition to New Email Threading Behavior’ Release Update postponed until Summer ‘23. 
  • Your feedback has been extremely helpful as we focus on solutions for:
    • Threading strategy for notification, bounce emails and auto responses.
    • Use of process builder with new threading mechanism for inbound and outbound emails
    • Support of the new email threading behavior via Apex

We are working to update the knowledge article and accompanying FAQ with the various questions you’ve been posting over the past several months. 

 

NOTE: The option to opt-out of the new threading behavior until Summer '23 is only available to customers who already have Email-to-Case enabled before the Winter '21 release. If you created a new org, OR enabled Email-to-Case in an existing org after Winter '21, the new threading behavior will be the default behavior.    Please continue to post your feedback to this thread and @mention Jared Long.

228 条评论
0/9000

Hi all, 

 

I have, in our sandbox, enabled the Release Update called "Disable Ref ID and Transition to New Email Threading Behavior". 

 

I'm very concerned about this coming change since we have a lot of processes running that is using the Thread Id's. For example when we need a mail to be attached to a specific case (e.g. a Bounce message from Salesforce), we just add the Thread ID of the original case and send it into Salesforce and it's correctly connected to the case we want it to be connected to. 

We also use the Thread Id's in a link in our autoreplies templates. 

 

I have also tested the Release Update with just replying to a mail from a case and also that does not work. I have an ongoing Support case towards Salesforce Support but I just want to check if anyone here experience the same issues with this Release Update? 

 

Link to the release note: 

https://releasenotes.docs.salesforce.com/en-us/winter21/release-notes/rn_email_to_case.htm

 

Br

Madelene Wärja 

146 条评论
  1. 2024年5月22日 10:17

    I have worked on the new feature Email Threading. its working fine.

    for that, the email id, which is used in Email to Case is same as from email address in Email Alert  and org wide email Address

0/9000

I'm creating an Auto Response Email indicating to a client that a Support case has been created.  As part of the email we are allowing the client to respond back to this email.

 

Question:  If the client responds back to the email will the response be recorded against the newly created case?  Do I need to add the Thread ID field to both the subject and the body?

 

Thanks

 

#Service Cloud #Email-to-case #Email Template #Email Threading #New Email Threading Behavior

2 个回答
  1. 2024年4月25日 09:55

    Salesforce migrated from Thread ID to Message header and if upgrade is already done in your org, then customer reply will automatically get attached to existing thread without Ref ID. 

    But if org is still relies on Thread ID, then Salesforce identifies if its reply to existing email using Thread ID in either email subject or body, so it has to be included in one of these places.

    Note: There is also lightning threading that Salesforce has introduced which is latest, so it depends on which settings is enabled. Refer to below link for more details,

     

    https://help.salesforce.com/s/articleView?id=sf.support_email_to_case_threading.htm&type=5

0/9000

In the release notes for this change, It states: 'Before you turn on Email-to-Case threading, verify that there’s data in the Message-ID, In-Reply-To, and References fields'

 

My understanding was originally that its all handled automatically from Salesforce when the email goes out. Does anyone know exactly what this is referring to? where do I verify that data is there?

7 个回答
0/9000

Email 2 Case Critical Update "Disable Ref ID and Transition to New Email Threading Behavior" and sending Emails through Apex gap.

 

Hello guys,

 

New Threading Behavior is a very exciting feature, we want to introduce it ASAP, so we started testing it and I think that we have found a gap. 

From what I understand, the new behaviour works as following:

  • Email is received on E2C.
  • Information from header: In-Reply-To, References are being matched with MessageIdentifier field on EmailMessage object.
  • If values have been matched, then EmailMessage received on E2C is linked to an existing Case (that is Parent of matched EmailMessage). Otherwise, new Case gets created.

This works perfectly fine with responses to Emails created via Standard features (Case auto-response, Send Email quick action) as MessageIdentifier field gets correctly populated for the emails send.

 

However, in our org we have some other complex scenarios where we require to send emails via Apex. We have tested 2 methods from Messaging class:

  • Messaging.sendEmail(emails, allOrNothing) - we send SingleEmailMessage and then create EmailMessage object based on it (connected to Case via ParentId). 
  • Messaging.sendEmailMessage(emailMessageIds, allOrNothing) - We insert EmailMessage as a draft and then send it using this method.

Neither of those ways gives us any opportunity to populate MessageIdentifier field on EmailMessage object, as it seems that this information is not avaliable in Apex. Moreover, it seems that MessageIdentifier is Read Only (if you populate it programatically before inserting the EmailMessage, it is set to '' anyway.

 

Is my reasoning correct? Are there any enchancements to facilitate that scenario planned before "Disable Ref ID and Transition to New Email Threading Behavior" critical update is enforced? Does it mean that responses to EmailMessages sent via Apex won't work with E2C New Email Threading Behavior?

 

CC: @Zakaria Aoujil @Piotr Wyszynski @Dominik Ryczek

5 条评论
  1. 2022年1月5日 11:54
    • I'm getting : In-Reply-To, References are being matched with MessageIdentifier field on EmailMessage object.
    • Parent Id not getting . I'm getting : In-Reply-To, References are being matched with MessageIdentifier field on EmailMessage object.Parent Id not getting . What to Do ??? So pls guide...
    • What to Do ???  So  pls guide... 
0/9000