System.InvalidParameterValueException: You don't have access to the getCaseIdFromEmailThreadId apex method. Use getCaseIdFromEmailHeaders instead

Question

Spring 25 sees a Release Update enforcement of the latest Email-to-Case threading mechanism Disable RefId and Switch to Lightning Threading

• I have an org that is still using RefId threading

• I want to ensure that once I switch to Lightning Threading, that incoming emails containing the old RefId thread token will still match to the Case in the event that Lightning Threading Token fallback strategy (header-based threading) fails.

• Given that my code can inspect the incoming email and detect the RefId threadId (e.g. ref:!00DXXXXXXX.!5000XXXXXXX:ref )

  • I can use the (deprecated) method to find the caseId Id caseId = Cases.getCaseIdFromEmailThreadId(refId)

However, when I use this, I get the error:

System.InvalidParameterValueException: You don't have access to the getCaseIdFromEmailThreadId apex method. 
Use getCaseIdFromEmailHeaders instead.

I tried with Apex class versions 46 - 60; same error. How do I resolve?

Answer 1

This error ensues as soon as you enable the Release Update Disable RefId and Switch to Lightning Threading.

• If you disable the Release Update, the method works fine

Although the error states use getCaseIdFromEmailHeaders instead, this doesn't apply to my use case as I know that some incoming emails have the SFDC headers stripped off by our secure messaging platform.

So, for my org at least, before I turn on the Release Update, I will ensure that every Case is updated using a custom field Case.RefId_Token__c with the RefId. There are different approaches to get this:

• From the actual EmailMessage sent from a Case using Regex.

• Using the October 2023 formula as outlined in this Idea - possibly fragile as refId format has changed over time

• Using a non-bulkified method

    List<Messaging.RenderEmailTemplateBodyResult> renderResults =
          Messaging.renderEmailTemplate(null, caseId, new List<String>{'{!Case.Thread_Id}'});
  

Then, any inbound email that creates a new Case that contains a RefId can be matched against existing cases that have the custom field populated. Fortunately, as a new Case, the RefId will be in the Case.Description so you can

• Avoid sending out case auto-response rules
• Avoid Case assignment rules from running
• Merge the new Case with the matching Case using Database.merge (do this async)