Salesforce フロー制限の完全ガイドとその回避方法

[Flowに関するまとめページに戻る](https://qiita.com/Keiji_otsubo/items/55ebc9c634a3216f3990)

--------
+ [Complete Guide to Salesforce Flow Limits and How to Avoid Them](https://www.salesforceben.com/complete-guide-to-salesforce-flow-limits-and-how-to-avoid-them/)

Salesforce フローのスキルを次のレベルに引き上げたい場合は、「一般」および「ガバナー」の制限に慣れる必要があることは避けられません。 

これらの制限は、最初は難しそうに思えるかもしれませんが、最も重要な概念と最も一般的な制約 (および Salesforce フローの制限に達するのを回避する方法) を平易な言葉で説明し、より簡単に理解できるようにします。 

# 重要な概念

始める前に、知っておく必要のある概念がいくつかあります。

**なぜ制限があるのですか？**

Salesforce はマルチテナント環境です。つまり、複数の組織が同じインスタンスのリソースを共有します。誰も容量を占有しすぎないようにするために、Salesforce はこれらの制限を適用して、各クライアント   の使用を管理しています。

**フローのインタビューとトランザクションとは何ですか?**

インタビューは、フローの実行中のインスタンスであり、そのフローの 1 つの完全な実行です。一方、トランザクションは、1 つの単位として実行される一連の操作です。フロー インタビューは、トリガー、エスカレーション ルールなど以外の操作のタイプの 1 つです。これは、フロー インタビューが常にトランザクション内で実行されることを意味します。

ただし、複数のフロー インタビューを同じトランザクションで実行できます。また、1 つのフロー インタビューを複数のトランザクションで実行することもできます。最初のケースはフローのバルク化によるもので、2 番目のケースは「単一ユニット」と見なされるものに依存します。これらについては後で詳しく説明しますが、現時点では、フロー インタビューはトランザクションではなく、さまざまな制限が適用されることを覚えておくことが重要です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/2712d2a5-eaa2-56e0-747a-c6e1f2d17918.png)

**SOQL と DML とは何ですか?**

SOQL と DML は、異なる操作を処理する 2 つの言語です。SOQL はデータを取得するためのもので、DML はデータを変更するためのものです。フローでは、データ要素 (ピンク色の要素) のみがこれらの操作を呼び出します。「Get Records」は SOQL を使用し、「Create/Update/Delete Records」は DML をいくつかのバリエーションで使用します。

# 一般的な制限

Salesforce フローの制限をすべて知っておくと便利ですが、初期段階でヒットする可能性が高い制限に焦点を当てましょう。

**フロー インタビューごとの制限**

+ 実行時にフローごとに実行される要素: 2,000

フロー インタビューごとに、最大 2,000 個の要素しか実行できません。ループがある場合、ループ内の要素 (ループ要素を含む) は反復回数で乗算されることに注意してください。たとえば、要素が 2 つのループに入るレコードが 100 件ある場合、要素の合計は 200 になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/5244c70b-2820-2d0e-05a4-7fa8bf2ab608.png)


**トランザクションごとの制限**

+ 発行された SOQL クエリの総数: 100
 データを取得するデータ要素は最大 100 個までしか使用できません。 

+ 発行された DML ステートメントの総数: 150
 データを変更するデータ要素は最大 150 個までしか使用できません。(これらの要素がループ内にある場合、これらの要素も乗算されることに注意してください。そのため、ベスト プラクティスとして「No Pink in Loop」とよく耳にします。) 

+ SOQL クエリによって取得されたレコードの総数: 50,000
 最大 50,000 レコードのみを取得できます。 

+ DML ステートメントの結果として処理されたレコードの総数: 10,000
 最大 10,000 レコードのみを変更できます。 

+ Salesforce サーバーの最大 CPU 時間: 10,000 ミリ秒
 CPU 時間は、サーバーがソリューションの処理に使用する時間です。最大値は 10,000 ミリ秒 (10 秒) です。

+ 1 つのバッチで許可される重複更新の総数: 12
 同じレコードを最大 12 回まで更新できます。

# 制限にぶつからないようにする方法
何よりもまず、可能な限り最も効率的な方法でフローを構築する必要があります。しかし、すべてのベスト プラクティスに従っても、フローがまだ限界に達している場合はどうなるでしょうか。答えは想像以上に簡単です。制限はフロー インタビューまたはトランザクションごとであるため、複数のフロー インタビューまたはトランザクションの生成を試みることができます。

**効率的なフローの構築方法**

フローをより効率的にする方法を常に考えるのは良い習慣です。これらのプラクティスに従うことで、制限に達するという問題に遭遇することさえないかもしれません:

+ データ要素を過度に使用しないでください。
+ ループ内でデータ要素を使用しないようにしてください。
+ 可能であればループをスキップします。
+ エントリー基準を厳しくする。
+ 変数と代入要素を利用してレコードを更新します。

**より多くのフロー インタビューを生成する**

大量のデータを処理する場合、通常、レコード数の制限よりも先に要素の制限に達します。これを防ぐには、レコード トリガー (RT) フローとスケジュール トリガー (ST) フローのバルク化機能を利用します。 

バルク化は複雑なトピックですが、次のアドバイスを覚えておいてください: RT/ST フローは、トリガー オブジェクトの 1 つのレコードであるかのように構築します。その後、Salesforce は可能な限りレコードをバッチ処理します。これは、要素の制約を効果的に回避するのに役立ちます。もう少し深く掘り下げたい場合 は、私の実験をご覧ください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/328136/5cc3edc9-8b98-7886-926e-b054ceba04db.png)

**より多くのトランザクションを生成する**

フロー インタビュー制限を回避しても、トランザクション制限に達する可能性があります。これを回避するには、複数のトランザクションの生成を試みることができます。「単一ユニット」の定義に戻ります。これは、一時停止せずに実行できる操作として理解できます。 

画面要素、スケジュールされたパス、および一時停止アクションはすべて、フロー インタビューを一時停止します。残りのフロー インタビューは、新しいトランザクションで実行されます。これは知っておくと便利なちょっとしたトリックですが、トランザクションが完了すると、操作をロールバックできないことに注意してください。これは、操作が既にコミットされているためです。

# 概要

各クライアントがリソースを公平に利用できるようにするために、Salesforce フローの制限が設けられています。一般に、2 つの異なる概念である 2 つの制限 (フロー インタビューごとおよびトランザクションごと) があります。これらの制限を回避するには、フローをできるだけ効率的に構築するか、バルク化機能を利用するか、トランザクションを分割します。 

この記事では、最も一般的な制限のみを取り上げました。すべての一般的な制限について知りたい場合は、[公式ドキュメント](https://help.salesforce.com/s/articleView?id=sf.flow_considerations_limit.htm&type=5)とその他のリソース をご覧ください。