Flowに関するまとめページに戻る

Complete Guide to Salesforce Flow Limits and How to Avoid Them

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

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

重要な概念

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

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

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

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

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

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

SOQL と DML とは何ですか?

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

一般的な制限

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

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

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

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

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

発行された 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 は可能な限りレコードをバッチ処理します。これは、要素の制約を効果的に回避するのに役立ちます。もう少し深く掘り下げたい場合は、私の実験をご覧ください。

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

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

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

概要

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

この記事では、最も一般的な制限のみを取り上げました。すべての一般的な制限について知りたい場合は、公式ドキュメントとその他のリソースをご覧ください。