プロセスはコーディングなしでもデータの更新や作成・削除から割り当て、メール送信など多くのことを実行できる便利な機能です。プロセスで実現できるようになります。プロセスにおいても制限事項があります。運用で一番インパクトがあったのが無限ループを回避するための制限でした。下記の技術情報にあるように、特定のレコードに対してプロセスが一定回数実行されると、無限ループとして検出されて「失敗」してしまいます。・・・作成するワークフローには、無限ループを検出して停止するためのロジックが含まれます。プロセスが、短時間に特定のレコードに対して一定の回数を超えて実行されると、次のエラーでそのプロセスは失敗します。ジョブは、それを開始したワークフローに無限ループが含まれるので取り消されます。ロジックを修正して、もう一度やり直してください。プラクティスこの制限事項には結構手を焼きまして、いろいろ試行錯誤して、どのタイミングで「失敗」してしまうのかがわかってきたので、その対策を含めてご紹介します。プロセスをどういったときに使うか。私はよく上位下位関係のあるエンティティのレコードを上位から下位に対して一括更新する時や、前後関係のあるレコードの一部を削除した際、後続するレコードを更新する時などに使います。下図のように営業案件に複数の活動が関連しており、これらの活動を開始の日付が古い順に番号を振りたいとします。ここで、営業活動側でロールアップフィールドを作成して、活動で開始が一番古い(MIN)の日付を持ってきて、その日付と一致した活動は一番古いだと判別できます。使って処理して行いました。この営業案件のフィールドを更新する処理を活動数分繰り返すのですが、営業案件にぶら下がる活動数が多い場合、簡単に16回の制限を超えてしまうので、プロセスが無限ループとして検出され「失敗」します。実行できるループの回数1プロセス内の1ステップでレコードの更新を行い、その後に「子ワークフローの実行」で同プロセスを再度呼んでループを繰り返す検証を行ったところ、実際は15回目で「失敗」となりました。レコードの更新が行われたのは、14回でした。(15回目の更新時に、無限ループ検出されている)そのため公式ドキュメントで記載されている16回よりも実際は少ないようです。回以上のレコード更新を行うことができるかの検証しました。ステップを追加して、営業案件レコードを更新後、同プロセスをループするようにしました。回目で「失敗」となりました。レコードが更新されたことになります。最初の検証とは大きな違いです。プロセスのステップ数を増やせば、より多く更新することができるはずです。これらの検証より、制限ギリギリまでループを実行したい場合は、1プロセス内でステップを多く活用して、同プロセスをループする方法が最適だとわかりました。どのように対策をしたらいいか?ただ、どんなに工夫をしてもループ回数制限にはひっかかります。どのようにループ回数制限とうまく付き合えばいいか。試行錯誤した結果、この方法であればうまくいくことがわかりました。(あくまで個人的なアイディアです。他にいい方法があればコメントください)上限を確認ループさせたいプロセスが最大何回実行できるかを把握します。今回の場合は、15回目で失敗するので、14回がMAXかと思います。14回実行されたらプロセスを停止するような条件文を追加しておけば、「失敗」が記録されることはないでしょう。使って、15回目以降の処理は、バッチで時間を空けて処理します。上記で設定した条件文のところで、「もし14回目になったら、バッチプロセスを作成するプロセスを実行する」のようなステップにしておきます。Process」を作成するエンティティとして設定します。レコードが更新された5分後に設定しました。ある営業案件をターゲットに実行します。箇所に設定しています。分後にバッチで実行される同プロセスで処理されることになりました。バッチ作成結果は下図の通りです。内容を見てみると、意図したとおりに作成されていました。力技ですが、これでうまくワークフロープロセスをループする処理が実行できました。今回は、少し曖昧な箇所(制限が16回と書いてありつつ、実際は15回目で失敗するところ)もある記事でしたが、ワークフロープロセスでどうしてもループを実行したい際のアイディアとして参考いただければと思います。この記事を読んだ方は他にこんな記事を読んでいます。