Salesforceにおけるフローのガバナに関しての備忘録をまとめてみました。
フローにおけるガバナ制限は大まかに2種類ある
はじめに、Salesforceのフローにおけるガバナには大まかに2種類あることはご存じでしょうか？
1つが「全般的な制限」、もう1つが「トランザクション単位の制限」です。
1つ目の「全般的な制限」というのはフロー全体で共有する上限値のようなものです。
フローの最大有効化数や1つのフローに保存できるバージョン数の制限（最大50個）などが該当します。
こちらは制限を超えないように適宜データの削除などを行うことで回避しなければならないものです。
2つ目の「トランザクション単位の制限」はその名の通りトランザクションごとに設定されている上限値です。
Salesforceのアドミンを勉強したことのある人であれば一度は聞いたことがある、「SOQL クエリで取得されたレコードの総数の上限が50,000件」といったものです。
こちらは1トランザクションごとリセットされます。
つまり「トランザクション単位の制限」の場合はフローのつくりを工夫することによって回避することが可能です。
Salesforce公式のフローの全体的な制限に関するドキュメントはこちら
Salesforce公式のフローのトランザクション単位の制限に関するドキュメントはこちら
トランザクション単位の制限を回避する実装案
では今回は、代表的な「トランザクション単位の制限」を2つほど上げそれぞれの回避策を考えてみます。
- Salesforce サーバーの最大 CPU 時間（10,000 ミリ秒）
- トランザクション内のDMLで処理されるレコードの総数（10,000レコード）
Salesforce サーバーの最大 CPU 時間を回避する実装案
CPU時間のリミットにてガバナに引っかかる状況として大量の処理をしロードが長すぎて落ちるということがよくあるかと思います。
この場合は以下の実装にて回避が可能です。
- 画面フローの場合は処理の区切りで画面を挟むことでトランザクションを切断する
- レコードトリガーフローの場合は更新処理などをスケジュール済みパスから実行させる
- レコードトリガーフローにて大量の明細レコードがループする場合はトリガーフローを複数作成しそれぞれでループする明細を絞り込みループさせる（偶数番目の明細レコードは1つ目のトリガーフローで処理し奇数番目の明細レコードは2つ目のトリガーフローで処理する）
トランザクション内のDMLで処理されるレコードの総数制限（10,000レコード）をこえてデータ処理を行う場合は基本的にApexなどを用いてバッチ化することが第一に挙げられるかと思います。
ただし実装内容によっては、Apexではなくフローで簡易的に実装を行うことも可能となり、以下の方法となります。
- スケジュール済みパスを用いて非同期でレコードの更新や作成を動かすことで1トランザクション内の更新から外す
- 画面フローの場合は分割してデータ処理を行い処理の間に確認画面を挟む（~オブジェクトのレコード●●件更新しましたといった画面を挟みオブジェクトで区切りそれぞれ確認画面を挟むなど）
上記の実装案はあくまでトランザクションを切るための策になるため、要件から外れない範囲で提案してみるのもありかと思います。
上記の実装案はあくまでトランザクションを切るための策になるため、要件から外れない範囲で提案してみるのもありかと思います。
トランザクション内のDMLで処理されるレコードの総数制限を回避する実装案