| 制限の種類 | 制限 |
|---|---|
| SOQL | トランザクションあたり 100 回の SOQL クエリ、 トランザクションごとに SOQL クエリによって 50,000 件のレコードが取得されます |
| DML | トランザクションあたり150 DMLステートメント、 ステートメントによって作成、更新、または削除されるレコードは 10,000 件 |
| CPU | トランザクションあたり10秒のCPU処理時間 |
大量のレコード
SOQL および DML の制限に達しないようにするには、フィルターを使用して、フローで取得および更新するレコードの数を最小限に抑えます。
スケジュール トリガー フローを四半期ごとに実行するように設定することはできません。そのため、このスケジュール トリガー フローは毎日実行されます。決定要素は、現在の日付が四半期の初日であることを確認します。そうである場合は、レコードの更新要素が組織内のすべての連絡先の [今四半期に連絡済み] チェックボックスをオフにします。フィールドがすでにオフになっているレコードのフィールドもオフにします。ただし、組織に 10,000 件を超える連絡先が含まれている場合、このフローは失敗します。[今四半期に連絡済み] がオンになっている連絡先のみを更新するようにフローを更新しましょう。
ループ
これらの制限に達しないようにするには、レコードの取得、レコードの作成、レコードの更新、またはレコードの削除の要素をループ内に配置しないでください。代わりに、それらをループの外側に配置します。
- レコードの取得:ループ の前
- レコードの作成、レコードの更新、レコードの削除:ループ の後
他の自動化によって開始されたフロー
フローが別の自動化によって開始された場合、そのフローはその最初の自動化のトランザクションの一部として実行されます。上記のガバナー制限はすべてトランザクションごとであるため、他の自動化によって実行されるものはすべて、トランザクションごとの制限にもカウントされます。
たとえば、Pyroclastic の組織には、処理に 9 秒の CPU 時間を要する複雑な Apex クラスがあります。次に、Apex クラスは自動起動フローを呼び出します。フローの実行には 2 秒の CPU 時間を要するため、トランザクション全体が 10 秒の制限を超えるため、フローは (Apex クラスとともに) 失敗します。Apex クラスに含まれる SOQL クエリ、DML ステートメント、取得されたレコード、または影響を受けたレコードが多すぎる場合も、フローは失敗します。
この制限を回避する最善の方法は、自動化を可能な限り効率的にすることです。Apex クラスの実行に 9 秒の CPU 時間を要する場合、簡素化または改善できる可能性が高くなります (Apex クラスにとって 9 秒は長い時間です)。9 ～ 10 秒かかるフローについても同様です。他の方法がすべて失敗した場合は、待機要素 (条件の待機、時間の待機、または日付までの待機) のいずれかを追加して、新しいトランザクションを開始します。