Administrator

【レコード保存時の動作】レコードトリガフローの順番は?

Administrator
この記事は約5分で読めます。

こんにちは、アンダーソンです。
Spring20から使えるようになり、結構皆さん使われているのではないかなと
思うこの機能。
トリガとなって動く機能が追加されたという事は、
レコードの保存時に実行される動きも変更されているという事。

という事で今回は一連の流れを再度確認しておきました。

スポンサーリンク

まずは順序

レコード保存時の実行順序はDeveloperの試験とかでも問われる重要な部分です。
結構忘れがちというかあれ?どっちが先だっけ?ってなるので、下記Helpをそのまま引用させていただきました。(引用元:トリガと実行の順序)

  1. 元のレコードがデータベースから読み込まれるか、upsert ステートメント用にレコードが初期設定されます。
  2. 要求から新しいレコード項目の値が読み込まれ、古い値を上書きします。要求が標準 UI 編集ページから行われた場合は、Salesforce がシステム検証を実行して、レコードについて次の点を確認します。
    • レイアウト固有のルールへの準拠
    • レイアウトレベルおよび項目定義レベルで必要な値
    • 有効な項目形式
    • 最大項目サイズ要求が Apex アプリケーションや SOAP API コールなど他の提供元から送信されている場合、Salesforce では外部キーのみを検証します。トリガを実行する前に、Salesforce がカスタム外部キーがオブジェクト自体を参照しないことを確認します。見積品目や商談品目など、複数行の品目が作成された場合、Salesforce はユーザ定義の入力規則を実行します。
  3. レコードの保存前に実行されるように設定されたレコードトリガフローを実行します。
  4. すべての before トリガが実行されます。
  5. すべての必須項目に null 以外の値が入力されていることの確認や、ユーザ定義の入力規則の実行など、システム検証のほとんどの手順がもう一度実行されます。Salesforce が標準 UI + 編集ページから要求が行われた場合に再度実行しない唯一のシステム検証は、レイアウト固有のルールの適用です。
  6. 重複ルールが実行されます。重複ルールが重複するレコードを特定してブロックアクションを実行した場合は、レコードが保存されず、after トリガやワークフロールールなどの後続のステップが実行されません。
  7. レコードはデータベースに保存されますが、まだ確定されません。
  8. すべての after トリガが実行されます。
  9. 割り当てルールが実行されます。
  10. 自動応答ルールが実行されます。
  11. ワークフロールールが実行されます。
  12. ワークフロー項目自動更新が存在する場合、レコードが再度更新されます。
  13. ワークフロー項目自動更新でレコードが更新された場合、標準の入力規則に加えて、before update トリガおよび after update トリガがもう一度 (さらに 1 回のみ) 実行されます。カスタム入力規則、フロー、重複ルール、プロセスおよびエスカレーションルールは再実行されません。
  14. 次の Lightning フロー自動化を実行しますが、順序は保証されません。
    • プロセス
    • プロセスによって起動されたフロー
    • プロセスまたはフローで DML 操作が実行されるときに、影響を受けるレコードに対して保存手順が実行されます。
  15. エスカレーションルールが実行されます。
  16. エンタイトルメントルールが実行されます。
  17. レコードの保存後に実行されるように設定されたレコードトリガフローを実行します。
  18. レコードに積み上げ集計項目が含まれる場合、またはレコードがクロスオブジェクトワークフローの一部である場合、計算が実行され、親レコードの積み上げ集計項目が更新されます。親レコードに対して保存手順が実行されます。
  19. 親レコードが更新され、さらにその親レコードに積み上げ集計項目が含まれるか、その親レコードがクロスオブジェクトワークフローの一部である場合、計算が実行され、親の親レコードの積み上げ集計項目が更新されます。親の親レコードに対して保存手順が実行されます。
  20. 条件に基づく共有の評価が実行されます。
  21. すべての DML 操作がデータベースで確定されます。
  22. メール送信など、確定後のロジックが実行されます。

今回新たに登場した、レコードトリガフローは3と17番目に現れるので、結構早め、遅めの処理になります。

僕的にあ、そうなんだ!ってなったのが、
ApexTriggerより早いのとプロセスビルダー系のLightningフローとは別のタイミングで実行されるんだって事でした。

プロセスビルダーって順序の保証がされていないけど、
結構組織で作成しているところは多いんじゃないでしょうか?
ApexTriggerとかって一つのオブジェクトに対して何十個も作成することってあまり
ないかと思うのですが、簡単に作成できるPBやフローって作成しがちなので、
この辺り注意しないといけない点でもありますね。

実験してみました

ほんとにプロセスビルダーより保存後フローの方が後なのか実験してみました。
やり方は簡単。同じ条件で始まるようにしておいて、PBもフローも同じ値を更新するように設定しました。

まずはPBです。作成更新時で条件はなしにしておきました。これでテスト1オブジェクトのテキスト項目は『プロセスで書き換え』になるはず。

よしよし

では次にフローを作ります。

保存後にして。。

これで実行してみましょう。

変更されましたね。最終的に値を変えたい場合は更新後フローがいいのかもです。

疑問点

14番目のプロセスまたはフローで DML 操作が実行されるときに、影響を受けるレコードに対して保存手順が実行されます。この文言が本当であれば今回の実装はもしかして無限ループになるんじゃないかと思いましたがとりあえずは大丈夫でした。

プロセスビルダーでDML操作→フローでDML操作ですがどちらも自分自身を更新しているので、またPB→フローの流れができるかと思いましたが、デバッグを確認したところ
Flowインタビューは各一回でした。

DMLrowsをみても最初の一回のみでPBやフローの分はカウントされていないようでした。コミット前だから?謎です。

注意点

レコードトリガフローもプロセスビルダーと同じく、順序の保証はされないようです。
ここは設計上の盲点になりがちなので、組織としてルールを決めておく方がいいような気もします。

フローだと条件分岐がPBよりしやすい(個人的見解です)ので複数の分岐を用意して
ApexTriggerのようにいろんなパターンに適応させるのがいいのではと思いました。