Apex 開発者ガイド
j
No Results
Search Tips:
- Please consider misspellings
- Try different search keywords
トリガーと実行の順序
レコードを insert、update、または upsert ステートメントを使用して保存する場合、Salesforce は一連のイベントを特定の順序で実行します。
Salesforce がサーバーでこれらのイベントを実行する前に、ブラウザーは、レコードに連動選択リスト項目が含まれているかどうかを JavaScript で検証します。この検証では、各連動選択リスト項目を指定可能な値に制限します。クライアント側では他に検証は行われません。
サーバー上の Salesforce は、イベントを次の順序で実行します。
- 元のレコードがデータベースから読み込まれるか、upsert ステートメント用にレコードが初期設定されます。
- 要求から新しいレコード項目の値が読み込まれ、古い値を上書きします。
Salesforce は、要求の種別に応じてさまざまな検証チェックを実行します。
- 要求が標準 UI 編集ページから行われた場合、Salesforce はレコードに対して次のシステム検証チェックを実行します。
- レイアウト固有のルールへの準拠
- レイアウトレベルおよび項目定義レベルで必要な値
- 有効な項目形式
- 最大項目サイズ
また、要求が標準 UI 編集ページのユーザーオブジェクトから行われた場合、Salesforce はカスタム検証ルールを実行します。
- 要求が見積品目や商談品目などの複数行品目の作成から行われた場合、Salesforce はカスタム検証ルールを実行します。
- 要求が Apex アプリケーションや SOAP API コールなど他のソースから行われた場合、Salesforce は外部キーと制限つき選択リストのみを検証します。トリガーを実行する前に、Salesforce がカスタム外部キーがオブジェクト自体を参照しないことを確認します。
- 要求が標準 UI 編集ページから行われた場合、Salesforce はレコードに対して次のシステム検証チェックを実行します。
- レコードの保存前に実行されるように設定されたレコードトリガーフローを実行します。
- すべての before トリガーが実行されます。
- すべての必須項目に null 以外の値が入力されていることの確認や、カスタムの入力規則の実行など、システム検証のほとんどの手順がもう一度実行されます。Salesforce が標準 UI + 編集ページから要求が行われた場合に再度実行しない唯一のシステム検証は、レイアウト固有のルールの適用です。
- 重複ルールが実行されます。重複ルールが重複するレコードを特定してブロックアクションを実行した場合は、レコードが保存されず、after トリガーやワークフロールールなどの後続のステップが実行されません。
- レコードはデータベースに保存されますが、まだ確定されません。
- すべての after トリガーが実行されます。
- 割り当てルールが実行されます。
- 自動応答ルールが実行されます。
- ワークフロールールが実行されます。ワークフロー項目自動更新が存在する場合、次の実行が行われます。
- レコードが再度更新されます。
- システム検証が再度実行されます。カスタム入力規則、フロー、重複ルール、プロセスおよびエスカレーションルールは再実行されません。
- レコードの操作 (挿入または更新) に関わらず、before update トリガーと after update トリガーがもう 1 回 (1 回だけ) 実行されます。
- エスカレーションルールが実行されます。
- 次の Salesforce フロー自動化を実行しますが、順序は保証されません。
- プロセス
- プロセスによって起動されたフロー
プロセスまたはフローで DML 操作が実行されるときに、影響を受けるレコードに対して保存手順が実行されます。
- レコードの保存後に実行されるように設定されたレコードトリガーフローを実行します。
- エンタイトルメントルールが実行されます。
- レコードに積み上げ集計項目が含まれる場合、またはレコードがクロスオブジェクトワークフローの一部である場合、計算が実行され、親レコードの積み上げ集計項目が更新されます。親レコードに対して保存手順が実行されます。
- 親レコードが更新され、さらにその親レコードに積み上げ集計項目が含まれるか、その親レコードがクロスオブジェクトワークフローの一部である場合、計算が実行され、親の親レコードの積み上げ集計項目が更新されます。親の親レコードに対して保存手順が実行されます。
- 条件に基づく共有の評価が実行されます。
- すべての DML 操作がデータベースで確定されます。
- 変更がデータベースにコミットされた後、コミット後ロジックが実行されます。コミット後ロジックの例を次に示します (順不同)。
- メールの送信
- キューに登録された非同期 Apex ジョブ (キュー可能ジョブや future メソッドを含む)
- レコードトリガーフローの非同期パス
その他の考慮事項
トリガーを使用する場合、次の点に注意してください。
- ワークフロールール項目の更新がレコード更新によってトリガーされた場合、Trigger.old には更新後にワークフローによって新たに更新された項目は保存されません。Trigger.old には、最初のレコード更新が行われる前のオブジェクトが保存されます。たとえば、既存のレコードに初期値が 1 の数値項目があるとします。ユーザーがこの項目を 10 に更新し、ワークフロールールの項目自動更新が起動されて項目が 11 に増えます。ワークフローの項目自動更新後に起動される update トリガーでは、Trigger.old から取得されるオブジェクトの項目値は、10 ではなく元の値の 1 になります。トリガーの更新前後の Trigger.old の値に関する説明を参照してください。
- 部分的完了が許可された DML コールが行われた場合、トリガーは最初の試行時に実行され、その後の試行時に再び実行されます。これらのトリガーの呼び出しは同じトランザクションの一部のため、トリガーがアクセスする静的クラス変数はリセットされません。「一括 DML 例外処理」を参照してください。
- 同じイベントについての 1 つのオブジェクトに、複数のトリガーが定義されている場合、トリガーの実行順序は保証されません。たとえば、ケースに 2 つの before insert トリガーがあり、新しいケースレコードが挿入されたとします。これらの 2 つのトリガーの起動順序は保証されません。
- 取引先責任者を複数の取引先に関連付ける公開された取引先責任者を組織に挿入した場合の実行順序については、「AccountContactRelation」を参照してください。
- before トリガーを使用して Stage や Forecast Category を設定している場合の実行順序については、「商談」を参照してください。
- API バージョン 53.0 以前では、エンタイトルメントの実行後に保存後レコードトリガーフローが実行されていました。