ポスト
目次
はじめに
今回は、Salesforceフローの中の「コレクション検索条件」という便利な要素を使ってループ内のレコード操作を回避した方法を紹介したいと思います。
Salesforce フローとは
フローとはSalesforce上で独自のプロセス処理が作成できるノーコードツールです。
今回はフローの概要については割愛して、「コレクション検索条件」に的を絞った記事になります。
フローについて詳細を知りたい方は以下の記事を参考にしてみてください。
今回はフローの概要については割愛して、「コレクション検索条件」に的を絞った記事になります。
フローについて詳細を知りたい方は以下の記事を参考にしてみてください。
【Salesforce フロー】とは？初心者なら知っておきたい５つのテク - TerraSkyBase | テラスカイを支える人とテクノロジーの情報を発信する基地局
Salesforceフローとは、Salesforce上で独自のプロセス処理が作成できるプログラムです。Salesforce フローを利用するとプログラムを書かなくても独自のプロセス処理の作成ができます。フローを使いこなすうえで知っておきたい５つポイントご紹介します。
「コレクション検索条件」とは
条件をコレクションに適用し、条件を満たす項目のみを含む新しいコレクションを出力する際に使えるフローの要素になります。
使用方法
単一値を含むコレクション変数、レコードを含むコレクション変数、Apex で定義されたコレクション変数など、Flow Builder で見つかったコレクションをすべて絞り込むことができます。
コレクション検索条件は、絞り込まれた結果のコレクションを出力し、ソースコレクションのコンテンツは変更しません。対応するコレクション検索条件が実行されるまで、出力コレクションは null です。
Salesforceヘルプより。
フローを修正してみよう！
文字だけではイメージしづらいと思うので、実際に「コレクション検索条件」を使ったフローを見てみましょう。
前提
まずは前提となる今回のゴールとオブジェクトの説明です。
実案件で「コレクション検索条件」使用時に想定通りに値が取得できずに困ったことがあったので、今回はその解決方法も記載したいと思い具体的な設定を作成しました。
★今回のゴール（実現したいこと！）
「申請データの承認日が翌日になっても取引区分が01または02の取引履歴レコードが取り込まれていない場合、朝9時にメールを送信したい。」
※メールには申請データの情報を載せたい
※翌日以降になっても取引履歴レコードが取り込まれていなかった場合は、翌日もメールを送りたい
★オブジェクトの説明
「申請」と「取引履歴」はカスタムオブジェクトで、両オブジェクトとも取引先と主従関係のオブジェクトであり、業務作業上「申請」レコードと「取引履歴」レコードは必ず1:1になる。
「申請」と「取引履歴」は直接のリレーションがなくても、「取引先」を介して対になるデータが取得できる。
「申請」には「承認日」という項目があり、「取引履歴」は「取引区分」という項目を持っている。
実案件で「コレクション検索条件」使用時に想定通りに値が取得できずに困ったことがあったので、今回はその解決方法も記載したいと思い具体的な設定を作成しました。
★今回のゴール（実現したいこと！）
「申請データの承認日が翌日になっても取引区分が01または02の取引履歴レコードが取り込まれていない場合、朝9時にメールを送信したい。」
※メールには申請データの情報を載せたい
※翌日以降になっても取引履歴レコードが取り込まれていなかった場合は、翌日もメールを送りたい
★オブジェクトの説明
「申請」と「取引履歴」はカスタムオブジェクトで、両オブジェクトとも取引先と主従関係のオブジェクトであり、業務作業上「申請」レコードと「取引履歴」レコードは必ず1:1になる。
「申請」と「取引履歴」は直接のリレーションがなくても、「取引先」を介して対になるデータが取得できる。
「申請」には「承認日」という項目があり、「取引履歴」は「取引区分」という項目を持っている。
修正前のフロー
★修正前フローの処理の流れ
発火条件：スケジュールトリガで毎朝9時にバッチが実行される
１. 「承認日」が本日日付より前の申請レコードを取得する
２. １で取得した申請レコードの回数分、３の処理を繰り替えし行う
３. 「取引区分」が「01または02」かつ「取引先」が「1で取得した申請レコードの取引先」と一致する取引履歴レコードを取得する
・取引履歴レコードが取得できなかった場合⇒メールアラートでメールを送信する
・取引履歴レコードが取得できた場合⇒処理を終了して次のループに入る
発火条件：スケジュールトリガで毎朝9時にバッチが実行される
１. 「承認日」が本日日付より前の申請レコードを取得する
２. １で取得した申請レコードの回数分、３の処理を繰り替えし行う
３. 「取引区分」が「01または02」かつ「取引先」が「1で取得した申請レコードの取引先」と一致する取引履歴レコードを取得する
・取引履歴レコードが取得できなかった場合⇒メールアラートでメールを送信する
・取引履歴レコードが取得できた場合⇒処理を終了して次のループに入る
修正後のフロー
★修正前フローの問題点
処理の流れ３.の取引履歴レコードの取得条件に申請レコードの項目を使っていて、申請レコード分取引履歴の取得を繰り返すためにループ内でレコード操作を行う必要がある。
しかし、フローのベストプラクティスとしてトランザクションごとの制限回避のために「No Pink in Loop（ループ内でデータ操作しない）」という考え方がある。
ループ内でレコード操作を回避するためにはどのように修正したらよいのでしょうか？
処理の流れ３.の取引履歴レコードの取得条件に申請レコードの項目を使っていて、申請レコード分取引履歴の取得を繰り返すためにループ内でレコード操作を行う必要がある。
しかし、フローのベストプラクティスとしてトランザクションごとの制限回避のために「No Pink in Loop（ループ内でデータ操作しない）」という考え方がある。
ループ内でレコード操作を回避するためにはどのように修正したらよいのでしょうか？
★修正後フローの処理の流れ
発火条件：スケジュールトリガで毎朝9時にバッチが実行される
１. 「承認日」が本日日付より前の申請レコードを取得する
２. 「取引区分」が「01または02」の取引履歴レコードを取得する
３. １で取得した申請レコードの回数分、４の処理を繰り替えし行う
４. 「取引先」が「2で取得した申請レコードの取引先と一致する取引履歴レコード」をコレクション検索条件で取得する
・取引履歴レコードが取得できなかった場合⇒メールアラートでメールを送信する
・取引履歴レコードが取得できた場合⇒処理を終了して次のループに入る
発火条件：スケジュールトリガで毎朝9時にバッチが実行される
１. 「承認日」が本日日付より前の申請レコードを取得する
２. 「取引区分」が「01または02」の取引履歴レコードを取得する
３. １で取得した申請レコードの回数分、４の処理を繰り替えし行う
４. 「取引先」が「2で取得した申請レコードの取引先と一致する取引履歴レコード」をコレクション検索条件で取得する
・取引履歴レコードが取得できなかった場合⇒メールアラートでメールを送信する
・取引履歴レコードが取得できた場合⇒処理を終了して次のループに入る
コレクション検索条件の部分の設定詳細は、以下のように設定しています。
★コレクション
GetTrihikiRireki（取引履歴レコードを取得する２.の処理結果）
★検索条件
項目：Account__c（取引先）
値：ループLoopShinseiRecordの現在の項目＞取引先
★コレクション
GetTrihikiRireki（取引履歴レコードを取得する２.の処理結果）
★検索条件
項目：Account__c（取引先）
値：ループLoopShinseiRecordの現在の項目＞取引先
修正後のフローをデバッグしてみよう！
まずは、承認日が前日以前の申請レコードデータのみを1件作成します。
この場合、申請レコードと対になる取引履歴が入っていない状態なのでメール送信対象となります。
デバッグの結果でもメール送信処理が実行されていることが確認できます。
デバッグの結果でもメール送信処理が実行されていることが確認できます。
次に、承認日が前日以前の申請レコード1件と申請レコードと同じ取引先に紐づく取引区分「01」の取引履歴レコードを1件作成します。
対になる取引履歴レコードを入れたことにより、メールが送信されない状態になりました。
対になる取引履歴レコードを入れたことにより、メールが送信されない状態になりました。
実際にデバッグして試してみます。
現在この組織には
承認日が前日以前の申請レコードデータが1件（メール送信対象）と
承認日が前日以前の申請レコード1件と申請レコードと同じ取引先に紐づく取引区分「01」の取引履歴レコード（メール送信対象外）
のデータが存在しているので、「取引履歴なし」と「取引履歴あり（終了）」の両方の分岐を通る想定なのですが、通っていないことが分かりました。
想定通りの処理が行われていないのはどこでしょうか？
デバックの詳細を見てみましょう！
承認日が前日以前の申請レコードデータが1件（メール送信対象）と
承認日が前日以前の申請レコード1件と申請レコードと同じ取引先に紐づく取引区分「01」の取引履歴レコード（メール送信対象外）
のデータが存在しているので、「取引履歴なし」と「取引履歴あり（終了）」の両方の分岐を通る想定なのですが、通っていないことが分かりました。
想定通りの処理が行われていないのはどこでしょうか？
デバックの詳細を見てみましょう！
デバッグの詳細
デバッグの詳細を見てみると、
ループ前の申請レコード取得と取引履歴取得の部分ではレコードの取得ができていること、ループ処理では2件のループ対象レコードが取得できていることが分かります。
ループ前の申請レコード取得と取引履歴取得の部分ではレコードの取得ができていること、ループ処理では2件のループ対象レコードが取得できていることが分かります。
では、今回のキーポイントとなる「コレクション検索条件」での処理部分を見てみましょう。
今回ループは2回通ります。
そのうちコレクション検索条件の結果の1件は結果が「なし」、1件は結果として値が取れている（メール対象外となるように取引履歴が1件取れている）のが正しい状態です。
詳細を見ると、想定通りの結果が取得できていることが確認できます。
今回ループは2回通ります。
そのうちコレクション検索条件の結果の1件は結果が「なし」、1件は結果として値が取れている（メール対象外となるように取引履歴が1件取れている）のが正しい状態です。
詳細を見ると、想定通りの結果が取得できていることが確認できます。
次に怪しいのが、取得したコレクション検索条件の結果がきちんと判定されているかどうかというところです。
決定の詳細を見てみると、2つ目の「コレクション検索条件：対象取引履歴取得」にはデータが入っているのにも関わらずnull＝trueになっていることが分かります。
コレクション検索条件「コレクション検索条件：対象取引履歴取得」の結果はコレクションなので、複数レコードが入っている可能性があるのにも関わらずnullかどうかという強引な判定をしようとしたからかもしれません。
決定の詳細を見てみると、2つ目の「コレクション検索条件：対象取引履歴取得」にはデータが入っているのにも関わらずnull＝trueになっていることが分かります。
コレクション検索条件「コレクション検索条件：対象取引履歴取得」の結果はコレクションなので、複数レコードが入っている可能性があるのにも関わらずnullかどうかという強引な判定をしようとしたからかもしれません。
修正したフロー
決定の条件を色々修正したり、コレクション検索条件の結果を変数に割り当てしてみたりしたのですが…
うまく値がとれなかったのでフロー自体を修正してみました！
以下が完成形の全体図です。
うまく値がとれなかったのでフロー自体を修正してみました！
以下が完成形の全体図です。
★修正後フローから修正した箇所
「対象取引履歴分繰り返し」という要素を追加して、コレクション検索条件で取得したレコード分繰り返し、決定（分岐）処理を行うように修正。
デバックの結果は以下の通りで、想定通りに2レコードのうちの1レコード分だけメール送信の処理が行われました！！！
「対象取引履歴分繰り返し」という要素を追加して、コレクション検索条件で取得したレコード分繰り返し、決定（分岐）処理を行うように修正。
デバックの結果は以下の通りで、想定通りに2レコードのうちの1レコード分だけメール送信の処理が行われました！！！
まとめ
「コレクション検索条件」はとても便利で使い方をマスターすればフローの組み方を工夫することができます。
また、今回の例のように業務要件上データが1レコードしか取れてこない想定の時もコレクション検索条件を使う際は（コレクション検索条件の結果の型はコレクションとなるので）、1レコードずつ処理を行うときはコレクション検索条件の結果で再ループさせなければならないことが分かったと思います。
（Apex開発のときはデータ型には気を付けるのですが、フローになると意識しづらいところだったので今回は解決するのに時間がかかってしまいました。まだまだ勉強が必要ですね。）
みなさんもフローをマスターして、良いSalesforceライフを送ってください。
また、今回の例のように業務要件上データが1レコードしか取れてこない想定の時もコレクション検索条件を使う際は（コレクション検索条件の結果の型はコレクションとなるので）、1レコードずつ処理を行うときはコレクション検索条件の結果で再ループさせなければならないことが分かったと思います。
（Apex開発のときはデータ型には気を付けるのですが、フローになると意識しづらいところだったので今回は解決するのに時間がかかってしまいました。まだまだ勉強が必要ですね。）
みなさんもフローをマスターして、良いSalesforceライフを送ってください。
49 件
