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 つの制限 (フロー インタビューごとおよびトランザクションごと) があります。これらの制限を回避するには、フローをできるだけ効率的に構築するか、バルク化機能を利用するか、トランザクションを分割します。
この記事では、最も一般的な制限のみを取り上げました。すべての一般的な制限について知りたい場合は、公式ドキュメントとその他のリソース をご覧ください。