Flow・外部連携読了目安 10分公開 2026-10-31 ／ 更新 2026-10-31

Salesforce レコード保存時の実行順序（Order of Execution）図解

このページには広告リンクを含みます。

保存時の実行順序の全体像：押さえる7地点

実行順序は、ページの保存ボタンでも API でも Apex の DML でも、レコードが保存されるたびに同じ考え方で進みます。全部を暗記するより、まず7地点を覚えるのが近道です。

保存の手順1から20の時間軸に、保存前フロー、beforeトリガー、入力規則、afterトリガー、保存後フロー、積み上げ集計、コミットの7地点を強調した図
20の手順のうち、設計で押さえる7地点

ポイントは「保存」と「コミット」が別だということです。ステップ7で保存されても、ステップ19のコミットまでは確定しません。途中で失敗すれば、全部が取り消されます。

次の表は、公式の手順を日本語で要約したものです。手順の番号は Winter ’27（API バージョン 68.0）の版で確認した内容です。版によって変わる場合があり、たとえば API 53.0 以前では保存後フローはエンタイトルメントルールの後に動きます。細部は公式で確かめてください。

手順 動くもの 設計で考えること
1 元のレコードの読み込み
2 新しい値の読み込みと最初のシステム検証 ユーザーの標準の編集画面と、商談商品などの明細の一括作成では、ここでもカスタムの入力規則が動く
3 保存前のレコードトリガーフロー 自分の項目の更新はここ
4 before トリガー 保存前フローが入れた値が見える
5 システム検証の再実行とカスタムの入力規則 3と4の値も検査される
6 重複ルール ブロックならここで終わり
7 保存（コミットはまだ）
8 after トリガー
9 割り当てルール
10 自動応答ルール
11 ワークフロールール 項目更新があると、トリガーがもう1回動く
12 エスカレーションルール
13 Process Builder、ワークフローから起動したフロー この中の順序は保証されない
14 保存後のレコードトリガーフロー 他のレコードの更新はここ
15 エンタイトルメントルール
16 親レコードの積み上げ集計 親にも保存の手順が動く
17 祖父母レコードの積み上げ集計 同上
18 条件ベースの共有の評価
19 コミット ここで確定する
20 コミット後の処理（メール、非同期 Apex、非同期パス） 失敗時には動かない

入力規則はいつ動く？値が入っている前提を確かめる

入力規則（ステップ5）の前に動くのは、保存前フローと before トリガーです。この順序から、設計の判断が決まります。

  • 保存前フローが入れた値は、入力規則の判定対象になる
  • 保存後フローや after トリガーの更新は、1回目の入力規則には間に合わない
  • 保存後フローが同じレコードを更新すると、その更新に対してまた入力規則が動く

冒頭の値引率の問題は、このどれかに当たります。自動で入れる値が入力規則の前提なら、保存前フローにします。逆に、値を自動で入れる処理が入力規則に落とされることもあります。自動化の更新も、入力規則の対象からは外れません。

重複ルールは入力規則の次（ステップ6）です。ブロックの設定で重複と判定されると、レコードは保存されず、after トリガーやワークフローなど後の手順は動きません。「重複でエラーになったのに、フローの通知メールが飛んだ」ということは起きない仕組みです。

保存前フローと保存後フローはどちらを使う？

判断の基準は、触るのが自分の項目か、他のレコードかです。同じレコードの項目更新を保存後で行うと、2回目の保存が走ります。

保存後フローが同じレコードを更新すると2回目の保存が走り、保存前フローなら保存は1回で済むことを比べた図
同じ項目を埋めるのに、保存が1回で済むか2回走るか
比べる点 保存前フロー（高速項目更新） 保存後フロー（アクションと関連レコード）
手順 3 14
入力規則との関係 入力規則の前 入力規則の後
同じレコードの更新 追加の DML なし DML が増え、2回目の保存が走る
他のレコードの更新 できない できる
メールなどのアクション できない できる
サブフロー 呼べない 呼べる

Salesforce のヘルプは、保存前の更新なら再保存を省け、割り当てルールやワークフローなどをもう一度動かさずに済むと説明しています。判断ガイドも、項目だけを変えるなら保存前を使うよう勧めています。呼び出し可能な Apex は保存前では使えないため、保存前で済ませたいときは Flow の標準の要素か before トリガーで作ります。

順番が決まっていない場所

順序が保証されない場所も、知っておくべき点です。

  • 同じイベントの複数の Apex トリガー：同じオブジェクト・同じイベントに複数のトリガーがあると、順番は保証されません。判断ガイドは1オブジェクト1トリガーを勧めています。
  • Process Builder とワークフローから起動したフロー（ステップ13）：順序は保証されません。順番を決めたいならレコードトリガーフローに移します。
  • 同じ種類のレコードトリガーフロー：トリガー順序の値（1〜2,000）で並べられます。

トリガー順序の値には限界があります。保存後フロー同士の順番は変えられますが、保存後フローを before トリガーや保存前フローより先に動かすことはできません。

保存がもう一度動くケースと、親レコードへの波及

実行順序で見落としやすいのが、1回の保存から別の保存が生まれる場面です。

場面 何が起きるか 注意点
ワークフローの項目更新 レコードを再更新。システム検証をやり直し、before・after update トリガーがもう1回だけ動く カスタムの入力規則、フロー、重複ルール、Process Builder、エスカレーションは再実行されない
再帰保存 手順9〜17は飛ばされる 割り当てルールから積み上げ集計までは繰り返されない
積み上げ集計 親レコードにも保存の手順が動く 親の自動化も同じトランザクションの枠を使う
保存後フローの同じレコード更新 新しい DML が走り、レコードが保存の手順を通る エントリー条件で変化時に限定する

公式の資料は、2回目の保存の範囲を少し違う言い方で説明しています。判断ガイドは保存の順序全体がもう一度動くと書き、Apex 開発者ガイドは再帰保存では手順9〜17を飛ばすと書いています。保存後フローの更新で手順ごとに何が動くかは、どちらの資料にも一覧がありません。入力規則（手順5）は飛ばす範囲の外で、ヘルプもレコードトリガーフローはカスタムの入力規則を動かすと書いているので、動く前提で設計します。ほかの手順はデバッグログで確かめてください。

子の保存で親の積み上げ集計項目が更新されると、親のフローやトリガーも動きます。大量の子を保存したときに「親の側の処理」でガバナ制限に当たることがあるのは、このためです。枠の数え方はループ内DMLの記事で説明しています。

再帰の止め方として、判断ガイドは静的なフラグより、対象の項目が変わったときだけ動かす方法を勧めています。Apex なら Trigger.new と Trigger.oldMap の比較、フローならエントリー条件で $Record と $RecordPrior を比べます。

コミット後の処理と失敗時の動き

メール送信、非同期 Apex、レコードトリガーフローの非同期パスは、コミットの後（ステップ20）に動きます。これには2つの意味があります。

  1. 途中で失敗すれば、これらは動かない。コミット後に送るメールも送られない
  2. 非同期パスは元の保存と別に動くので、失敗しても元の保存は取り消されない

外部システムへの要求を非同期パスで送るのは、この性質を使ったものです。プラットフォームイベントはこの点で性質が違います。詳しくは外部システムとの連携パターンにまとめました。

関連記事

よくある質問

Salesforce の保存時の実行順序で、入力規則はいつ動きますか？
カスタムの入力規則は、保存前フローと before トリガーの後、レコードの保存の前に動きます。そのため保存前フローが入れた値は入力規則の判定対象になります。
保存前フローと Apex の before トリガーはどちらが先ですか？
保存前のレコードトリガーフローが先です。公式の順序では保存前フローがステップ3、before トリガーがステップ4で、その後に入力規則が続きます。
保存後フローは after トリガーより先に動かせますか？
動かせません。トリガー順序の値で調整できるのは同じ種類のフローの中の順番だけで、保存後フローを before トリガーや after トリガーより前に動かすことはできません。
実行順序は全部覚える必要がありますか？
全部を暗記する必要はありません。保存前フロー、before トリガー、入力規則、after トリガー、保存後フロー、積み上げ集計、コミットの7地点を押さえ、細かい手順は公式の Triggers and Order of Execution で確かめます。