2024年10月リリースのWinter25ではフローの「変換」要素がまた進化しました。
フローを触ったことがある人であれば何度も遭遇する
「ループを使わないと実現できない処理」が、また1つ減りました。
関連レコードの一括取得ではもうループは必要ありません。
そもそも「変換要素とは」という方は、まずは下記記事をご覧ください。
変換要素はどう進化したのか
従来は「レコード」「Apex定義」の2つのみ選択可能でしたが、
今後はテキストや日付など多くの主要データ型をサポートします。
●従来↓
●Winter25～↓
“次に含まれる”演算子とは
そもそも、従来から優秀な演算子である”次に含まれる”とはどういったものでしょうか。
・Winter23（2022年10月）に初登場
・SQLでいうIN句にあたる
・「レコードの取得」「レコードの更新」「レコードの削除」要素で使用できる演算子の1つ
という特徴があります。
「SQLでいうIN句」では複数の条件を指定してレコード検索場合に使用するクエリです。
●例：3名を検索する際
・IN句を使わない場合 ＝従来のフローに相当
SELECT * FROM user WHERE name = ‛若杉‛ OR name = ‛南山‛ OR name = ‛谷口‛;
・IN句を使う場合 ＝Winter25以降のフローに相当
SELECT * FROM user WHERE name IN(‛若杉‛, ‛南山‛ , ‛谷口‛);
このように、(‛若杉‛, ‛南山‛ , ‛谷口‛)というコレクション変数に対象文言が含まれるかを簡単に条件指定できます。
Salesforceのフロー上では下記のような場所で条件指定の演算子として使用できます。
“次に含まれる”演算子の弱点
Winter25時点では、唯一かつ致命的な弱点として「レコードコレクション型には使用できない」というものがあります。
「レコードコレクション型では”次に含まれる”は使用不可」となるため、レコードコレクションのみ保持している状態では
・レコードコレクションをループする
・ループ内で割り当て要素を使って、1レコード毎にテキストなどのコレクションへ追加する
ということが必要でした。
レコードコレクション内のレコード数が多いとループの負荷は大きくなります。
“次に含まれる”演算子の活用例 と 変換要素を使った進化
●”次に含まれる”演算子活用例
・[都道府県(請求先)] が [東京都] である私の取引先に所属する、すべての取引先責任者を取得する
ということを実現する場合を考えてみます。
従来も、今後も、手順は下記3つであることは変わりません。
手順①：[都道府県(請求先)] が [東京都] である取引先を全件取得
取引先をレコードコレクションとして本例では3件取得と想定
手順➁：①の取引先IDをループでテキストコレクションへ追加
①の取引先IDが[001xxxxxxxxxxxxxxa,001xxxxxxxxxxxxxxb,001xxxxxxxxxxxxxxc]というテキストコレクションとなるよう対応（＝レコードコレクションではなく）
手順③：➁のIDテキストコレクションで”次に含まれる”演算子を使い、対象の取引先責任者を取得
取引先責任者の取得条件として下記を実行
・取引先IDが”次に含まれる”：➁のテキストコレクション
ここで注目したいのが➁のIDをテキストコレクション化する部分です。
従来はループ内で割り当てを使い、1レコードずつIDをテキストコレクションへ追加するしかありませんでした。
Winter’25以降は変換要素を使い、ループ無しでテキストコレクション化が可能になります。
●従来
●Winter25～
従来の方法、変換要素を使う方法のいずれでも最後には「次に含まれる」演算子を使うことで対象取引先責任者を取得することができます。これは今まで通り”次に含まれる”演算子の威力です。
変換要素でテキストコレクション化
上記例で使用した変換要素の「取引先IDをテキストコレクション化」は下記のような形で使用します。
変換後にあたる「対象データ」ではテキスト型のコレクション変数としておきます。
ソースデータである取引先レコードコレクション変数の「Id」項目を変換元にすることで、取得した全取引先のIdをテキストコレクションに一括追加することができます。（＝ループが不要！）
まとめ
●”次に含まれる”演算子は従来から、関連レコードを取得する際の優秀な手段
●唯一の弱点を「変換」要素を使うことで克服し、ループの必要がなくなった
ということを見てきました。
今回の活用例に限らず、変換要素はアイデア次第でフローの弱点を補いうるものです。
今後も変換要素の進化を心待ちにしたいと思います。
