Salesforceはフローを使うことで非エンジニアでも気軽に自動化処理を構築できます。
処理の各種上限であるガバナ制限を意識しないと処理エラーになってしまいますが、フローでは一部の処理を自動で一括処理してくれるためガバナ制限に抵触しづらくなるという特徴があります。
ガバナ制限の主な制限
まずはSalesforceの基本的なガバナ制限を確認しましょう、この上限を超過すると処理エラーになります。
1トランザクション内で
・SOQL：実行は計100回まで、取得件数は計50,000件まで
・DML：実行は計150回まで、処理件数は計10,000件まで
Salesforceでの1トランザクションとは
処理の1塊のことをいいます。
たとえば取引先のレコードトリガーフローがある場合、そのフロー内での処理すべてを1トランザクションとして考えます。
一方で取引先のレコードトリガーフロー内で取引先責任者を更新しており、別途取引先責任者が更新されると起動するレコードトリガーフローがある場合は2つのフロー内での処理すべてを1トランザクションとします。
1フロー1トランザクションではなく、1連の処理の塊が1トランザクションという点がポイントです。
SOQLとDMLの発生カウント
Salesforceのフローでは各要素を1回実行するごとに下記がカウントされます。
・レコード取得 → SOQLのみが発生
・レコード作成 → DMLのみが発生
・レコード更新
（条件検索あり） → SOQL＋DMLが発生
（取得済み変数を渡す） → DMLのみが発生
・レコード削除
（条件検索あり） → SOQL ＋ DMLが発生
（取得済み変数を渡す） → DMLのみが発生
（ご参考）Salesforce社のヘルプサイト：トランザクションのフローで下記の例が紹介されています。
DMLとSOQLについては本記事時の次の章で紹介します。
例：データローダーで 100 件のケースを更新します。トランザクションの実行順序および組織のカスタマイズによって、次の操作が実行されます。
| STEP | トランザクションの操作 | 使用する DML ステートメント | 使用する SOQL クエリ |
|---|---|---|---|
| 1 | データベースにケースが保存されますが、まだ確定されていません。 | いいえ | 不可 |
| 2 | ケースの割り当てルールが実行されます。各ケースの所有者が更新されます。 | あり | 不可 |
| 3 | ケースのエスカレーションルールが実行されます。ケースが 10 日間オープンの場合、所有者にメールが送信されます。 | いいえ | 不可 |
| 4 | プロセスが開始されます。 | いいえ | 不可 |
| 5 | プロセスがケースの取引先を検索します。 | いいえ | あり |
| 6 | 取引先が「見込み有り」の場合は、プロセスが Chatter を使用して、取引先に関連付けられた新しいケースがあることを取引先所有者に通知します。 | あり | 不可 |
| 7 | プロセスがフローインタビューを起動します。 | いいえ | 不可 |
| 8 | フローインタビューが、ケースの親取引先とその取引先が有するケースの件数を検索します。 | いいえ | あり |
| 9 | フローインタビューが、取引先のオープンケースが 6 件以上かどうかを確認します。 | いいえ | 不可 |
| 10 | その場合は、フローインタビューが取引先のディビジョンマネージャーを検索し、取引先の Chatter フィードに投稿して、ディビジョンマネージャーと取引先所有者に通知します。 | はい | はい |
| 11 | そうでない場合は、フローインタビューが取引先の Chatter フィードに投稿して、取引先所有者のみに通知します。 | あり | いいえ |
フローは自動で一括処理を適用してくれる
パターン1：取引先トリガーフローAで取引先責任者が一括更新され、連動してフローBが起動する
【フローA：取引先レコードトリガーフロー】
取引先更新でトリガーし、その子である全取引先責任者を更新する。
【フローB：取引先責任者レコードトリガーフロー】
フローAで取引先責任者が更新されたことをトリガーに、フローBが起動しその取引先責任者を更新する。
●疑問
1取引先に10名の取引先責任者がいる場合、この一連のトランザクション（フローAとフローBの合計）でのSOQLとDMLの回数は？
●回答
・フローAで「検索条件なしのレコード更新」を1度実行したためSOQLが0回、DMLが1回、
・フローBでは10件分の取引先責任者が更新されるためフローBが10回起動すると思いきや、実際は内部で10件分がまとめて一括処理されるので「検索条件なしのレコード更新」を1度だけ実行したことになりSOQLが0回、DMLが1回となる。
→結果的にフローAとフローBの合計でSOQLが0回、DMLが2回となる。
●ポイント
フローAで10件の取引先責任者が更新されたが、フローBは10件分をまとめて1回だけで処理する内部処理となる。
※もしフローB内で2つに分岐する処理がある場合（例えば検索条件なしのレコード更新を1回するという”分岐1″に3件、レコード作成を2回するという”分岐2″に7件が進む場合）、フローBとしては分岐1でDML1回（3レコード分を一括処理）、分岐2ではDMLを2回（7レコード分を一括処理）のため、フローAと合わせるとDMLが4回となる。
パターン2：パターン1の状態でデータローダにて取引先を一括更新する
●疑問
パターン1と同じく1取引先に10名の取引先責任者がいる場合、この一連のトランザクション（フローAとフローBの合計）でのSOQLとDMLの回数は？ただし100行の取引先が記載されているCSVをデータローダにてバッチサイズ200で一括処理する。
●回答
・フローA：取引先100行分が一括更新されるのでフローAが100回起動すると思いきや、内部処理でバッチサイズの塊ごとに一括処理されるのでフローAは1回だけ起動。よってパターン1と同じく「検索条件なしのレコード更新」を1度実行しSOQLが0回、DMLが1回。
・フローB：100取引先×10取引先責任者分をまとめて処理しますが、1000行を一括処理するか、いくつかに分割するかは場合によるようです。多くの場合は1つの塊での更新は200行ほどになることが多いためSOQLが0回、DMLが1〜5回となることが多いようです。
→結果的にフローAとフローBの合計でSOQLが0回、DMLが2〜6回となることが多い。
パターン3：スケジュールトリガーフローで取引先を一括更新する
●疑問
取引先のスケジュールトリガーフロー。フロー内にはレコードの更新（条件検索あり）要素が1つだけ。その時刻のトリガー対象の取引先が5000件の場合のSOQLとDMLの回数は？
●回答
5000回フローが起動するのではなく、フローが1度起動して5000件を一括処理する。
検索条件を指定したレコード更新要素なので5000件の更新合計でSOQLが1回、DMLが1回となる。
※ガバナ制限としては一度のDML処理件数上限は10000件のため、フロー内のDML要素数や処理件数によっては10000件を超過してしまわないように注意が必要。
まとめ
Salesforceフローは自動で一括処理を適用してくれるので、1トランザクションでの処理負荷は少し軽減されるということを確認しました。
ループ内でSOQLやDMLを実行しないだけでガバナ制限に達する可能性は低くなります。
下記のように1トランザクション内でのSalesforceガバナ制限を意識すると良いでしょう。
・SOQLの実行回数100回、DMLの実行回数150回はフローが自動で一括処理してくれるため達する上限に達する場面は比較的多くありません（ループ内でSOQLやDMLを実行しない限り）。
・一方でSOQLでの取得上限50000件やDMLの処理上限10000件というのはフロー内で自動で一括処理されたとしても合計レコード件数は変わらないため、比較的上限に達しやすくなるため注意が必要です。
1フローでの使用要素数上限2000個という制限は数年前に撤廃されましたが、他にもCPUタイムエラーはあります。
処理の時間がかかりすぎると処理エラーになるため、上記の件数に収まったとしても必ずガバナ制限に抵触しないかと言えばその保証はありません。実際のSalesforce環境で大量レコードでテストをするくせはつけましょう。
