3

Why is SFDC not appending the new email to the existing case in sandbox? We have setup a typical on demand Email-to-Case service, as we normally do, but in sandbox, because refresh of Sandbox does not bring through the production Email-to-Case services. (This is not our first rodeo).

Setup: Enhanced Email has been turned on. Email-to-Case Service Setup and Verified. Routing "Email Address" : sandbox@ourdomain.com" is on gmail as a alias/group and happily redirects the emails to the Email-to-Case Service (hence the verification worked) Service email address : "sandbox@gsajdfnvs2osjdfnv...sadfv.cs57.case.sandbox.salesforce.com"

On a new case we send email to our colleague@ourdomain.com It includes the Ref Id in subject and body. We then respond to the received email using our colleagues inbox but replace the To address with the new redirect email address "sandbox@ourdomain.com"

The email is received by Salesforce and by our group members inboxes. But Salesforce creates a new Case rather than appending it to the existing one of the same ref Id.

This is the same result as if we just sent an email to the salesforce service address including the Ref Id.

Why is SFDC not appending the new email to the existing case in sandbox?

UPDATE 18/7 : It seems that Enhanced Email is the Cause, well at least we turned it off and Email-to-Case start working again. So it definitely looks like a bug, because I cannot find anything documented about Enhanced Email causing significant changes to Email-to-Case. UPDATE 19/7 : It is not enhanced Email we tested again and found non enhanced email sceanrio to still not work. It was an org refresh, and it used to work before sandbox refresh.

As a side the enhanced email also causes our sadbox (yes that was on purpose) to create duplicate emailmessage records, the duplicate does not have a parent, any info on this weirdness would be useful, maybe this will need a new question, but I have also asked this of salesfarce :) and will relay the results.

enter image description here enter image description here

This is the Thread Id equation we are using:

"ref:_" & LEFT($Organization.Id,5) & SUBSTITUTE(RIGHT($Organization.Id,11), "0", "" )& "._" & LEFT(Id,5) & SUBSTITUTE(Left(RIGHT(Id,10), 5), "0", "") & RIGHT(Id,5) & ":ref"
|improve this question
  • We also applied the same Routing email address as an org wide verified email address and used it in the sent email and hence replied to said email address. Seems to me like it is broken and the Ref Id is not being picked up. – NZ Dev Jul 17 at 3:48
  • does the new case have the same threadId as the original case (when you inspect the emails in the cases's related list)? Also +1 for "rodeo". FWIW, this is the kind of thing SFDC support can be of assistance with – cropredy Jul 17 at 4:48
  • Thanks :) Yes I have raise a partner Case (irony), and they are already looking at it. Will check the thread Id, but I would assume the thread Id is different. – NZ Dev Jul 17 at 13:54
  • turning off enhanced Email removes the problem, but we need enhanced email on. – NZ Dev Jul 17 at 14:01
  • 1
    1) when you use {!Case.ThreadID} in an email template, is the threadid the same as your formula 2) does it work with non truncated Ids i.e. "ref:_" & $Organization.Id & "._" & Case.Id & ":ref" 3) are you using a custom email handler? – user2610036 Jul 19 at 5:25
3
+50

Substituting the right 11 characters from the org id doesn't always work. Use 10 characters instead. The reason is that the 5 and the 11 will overlap causing a double up of the 5th character!

Use this code instead.

"ref:_" & LEFT($Organization.Id,5) & SUBSTITUTE(RIGHT($Organization.Id,10), "0", "" )& "._" & LEFT(Id,5) & SUBSTITUTE(Left(RIGHT(Id,10), 5), "0", "") & RIGHT(Id,5) & ":ref"

Edit: Note your formula assumes the 5th character is a 0 which is actually not always the situation. Hence the substitute will not remove it and now you have an extra unexpected character.

|improve this answer
  • 1
    Thank you that was the problem! Legend! My 5th org id char was not a zero and it was being included, when it shouldn't have been, looks like my formula was wrong to begin with, in production it was fine because the 6th char in the org Id was a zero. – NZ Dev Jul 19 at 5:36
  • Sorry 5th and 5th – NZ Dev Jul 19 at 5:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.