背景

2021 Winter以前から利用している企業では、Email-to-Caseのやりとりを取り込むのに、ref Idを利用しています。このref Idが曲者で乱数のように見えるものが、SubjectやBodyTextに自動で挿入されます。それは一種のマーカーのように機能してIncoming emailをref Idに該当するCaseに自動で紐付けます。

このref Idはときおり他企業からメールにも出てくるので、「あ、Salesforce使っているな」と推測したことのある方も多いのではないでしょうか。

乱数のように見えますがそうではなく以下のような規則があり、その規則に沿ってOrganizationId とCaseIdを組み合わせて、どの企業のどのケースから発せられたEmailMessageなのか、Incoming emailを関連付けていたようです。

これを数式化すると、以下のような組織IdをCase Idを魔法のレシピで混ぜ合わせたなかなかカオス規則で生成されているようです。

"ref:_" & //
LEFT($Organization.Id,5) &// 組織番号の左5桁
SUBSTITUTE(RIGHT($Organization.Id,10), "0", "" )& //組織番号の後方10桁で0を""に置換
"._" & LEFT(Id,5) & // CaseIDの左5桁
SUBSTITUTE(Left(RIGHT(Id,10), 5), "0", "") & //CaseID後方10桁のうち左5桁で0は""に置換
RIGHT(Id,5) & ":ref" //CaseIDの後方5桁

さらに、直近Winter ’24で桁数が変更になったり、結合の文字列が「_」だったのが「!」に変わったり、自作していた人たち（私も含む）はなかなかな展開です。

参照
メール-to-ケースの新しいスレッド動作によるセキュリティの強化
 The Ref ID Format for Email-to-Case is Changing
Email-to-Case Threading

Thread tokenの登場

このref idからthread tokenへの変遷は、2023/12/19に発表されたノートによると、ref Idからheader-threading、そしてlightning threadingへと紆余曲折があって移行されたようです。ユーザー間にも混乱が見受けられていました。

Disable Ref ID and Switch to Lightning Threading

Thread tokenにすると以下のようなthread::がEmail-to-Caseに差し込まれるようになります。設定は、Email-to-Case設定にある以下でsubjectやbodyに挿入を選びます。

ただこのメニューはこれまた設定にあるRelease UpdatesでDisable Ref ID and Tansition to New Email Threading Behaviourを承認しなくては有効になりません。ただし、Test Runもサポートされているので、Switchしてから様子を見てまた元に戻すということの可能です。

設定をオンにすると、Email-to-Caseで標準の返信などを利用すると以下のようなフォーマットのThread tokenが挿入されます。

thread::pp5XPGfmNf2hRZdRCWnrohc::　（例）

具体的な変更点

新しいEmail-to-Caseのスレッディング動作では、受信メールはref Idを使用して照合されません。代わりに、メールの件名または本文にある新しいセキュアトークンを使用して照合されます。一致するものが見つからない場合、メールヘッダーに含まれるメタデータも確認します。（ということで、仮にThread tokenが表題や本文に記載がなくても、Mail headerのMetadataに含まれている情報を参照して照合するとのことです）

移行による改善点

Ref ID threadingに似ていますが、token-basedのthreadingでは、メールの本文または件名にフォーマットされた文字列を挿入しますが、これは現在Salesforceのセキュリティ基準を満たすように生成されます。Lightning threadingが有効になると、新しい送信メールにはRef Idが含まれなくなります。（代わりにthread:xxxxx :threadが挿入、要設定）

組織への影響

Lightning threadingを有効にするまでEmail-to-Caseは互換性があります。新機能の自動有効化がオフの場合、Ref Id設定に基づいてスレッディングトークンの設定をします。メールテンプレートのMerge FieldはCase.Thread_IdからCase.Thread_Tokenにあります。（が、Merge Fieldのみの参照です）

カスタムコードはCases.getCaseIdFromEmailThreadIdからCases.getCaseIdFromEmailHeadersやEmailMessages.getRecordIdFromEmailに置き換えます。（こちらは後述のApex内でthread token取得に利用します）

移行中ケースのメールにはRef IdとThread tokenの両方とも含まれることがあります。

ApexによるThread tokenの取得

Flow内でのInvocable methodにしろ、Message methodを利用した送信にしろ、Email-to-Caseとして送信する場合はThread tokenを挿入しないといけないので、Apex内でThread tokenを取得します。

取得はとても簡単で、以下にCase Idを投げ込むだけです。

String formattedToken = EmailMessages.getFormattedThreadingToken(caseId);

こちらで生成されたものをSubjectやBodyに挿入するか、
getFormattedThreadingToken(recordId)

こちらで生成して、mail.setReferencesにつけて作成もできます。
generateThreadingMessageId(caseId)

@AuraEnabled
    public static string returnTokens(String recordId){
    return EmailMessages.getFormattedThreadingToken(recordId);
}

まとめ

作成してみると、Caseにつき1 Thread tokenで、これは何度取得しても、どの方法でやっても同一です。一意を保つSecure tokenという形でref Idを置き換えることができ、動作も想定通りなので今のところ問題はありません。
また、2021 Winter移行にSalesforceを導入した組織の場合はデフォルトですでにThread token形式になっているとのことで、そちらも併せてご確認ください。
遅くてもSpring '25 にはLightning threadingが強化されるのでそこら辺までにはRef Idを卒業しておく必要があります。

参照

こちらにFlow actionで利用するInvocable methodと通常LWCで利用するmethodを挙げておきます。