この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。
英語に切り替える

トリガと実行の順序

レコードを insertupdate、または upsert ステートメントを使用して保存すると、Salesforce は次のイベントを順番に実行します。

Salesforce がサーバでこれらのイベントを実行する前に、ブラウザは、レコードに連動選択リスト項目が含まれているかどうかを JavaScript で検証します。この検証では、各連動選択リスト項目を指定可能な値に制限します。クライアント側では他に検証は行われません。

メモ

サーバで、Salesforce により次の手順が実行されます。
  1. 元のレコードがデータベースから読み込まれるか、upsert ステートメント用にレコードが初期設定されます。
  2. 要求から新しいレコード項目の値が読み込まれ、古い値を上書きします。
    要求が標準 UI 編集ページから行われた場合は、Salesforce がシステム検証を実行して、レコードについて次の点を確認します。
    • レイアウト固有のルールへの準拠
    • レイアウトレベルおよび項目定義レベルで必要な値
    • 有効な項目形式
    • 最大項目サイズ
    要求が Apex アプリケーションや SOAP API コールなど他のソースから送信されている場合、Salesforce では外部キーのみを検証します。トリガを実行する前に、Salesforce がカスタム外部キーがオブジェクト自体を参照しないことを確認します。

    見積品目や商談品目など、複数行の品目が作成された場合、Salesforce はユーザ定義の入力規則を実行します。

  3. すべての before トリガが実行されます。
  4. すべての必須項目に null 以外の値が入力されていることの確認や、ユーザ定義の入力規則の実行など、システム検証のほとんどの手順がもう一度実行されます。Salesforce が標準 UI + 編集ページから要求が行われた場合に再度実行しない唯一のシステム検証は、レイアウト固有のルールの適用です。
  5. 重複ルールが実行されます。重複ルールが重複するレコードを特定してブロックアクションを実行した場合は、レコードが保存されず、after トリガやワークフロールールなどの後続のステップが実行されません。
  6. レコードはデータベースに保存されますが、まだ確定されません。
  7. すべての after トリガが実行されます。
  8. 割り当てルールが実行されます。
  9. 自動応答ルールが実行されます。
  10. ワークフロールールが実行されます。
  11. ワークフロー項目自動更新が存在する場合、レコードが再度更新されます。
  12. ワークフロー項目自動更新でレコードが更新された場合、標準の入力規則に加えて、before update トリガおよび after update トリガがもう一度 (さらに 1 回のみ) 実行されます。カスタム入力規則、重複ルール、およびエスカレーションルールは再実行されません。
  13. エスカレーションルールが実行されます。
  14. エンタイトルメントルールが実行されます。
  15. レコードに積み上げ集計項目が含まれる場合、またはレコードがクロスオブジェクトワークフローの一部である場合、計算が実行され、親レコードの積み上げ集計項目が更新されます。親レコードに対して保存手順が実行されます。
  16. 親レコードが更新され、さらにその親レコードに積み上げ集計項目が含まれるか、その親レコードがクロスオブジェクトワークフローの一部である場合、計算が実行され、親の親レコードの積み上げ集計項目が更新されます。親の親レコードに対して保存手順が実行されます。
  17. 条件に基づく共有の評価が実行されます。
  18. すべての DML 操作がデータベースで確定されます。
  19. メール送信など、確定後のロジックが実行されます。

再保存時は、ステップ 8 (割り当てルール) からステップ 17 (親の親レコードの積み上げ集計項目) までがスキップされます。

メモ

その他の考慮事項

トリガを使用する場合、次の点に注意してください。

  • 同一のイベントであるため、同一のオブジェクトに複数のトリガがある場合は、実行順序は保証されません。たとえば、ケースに 2 つの before insert トリガがあり、この 2 つのトリガを実行する新規ケースレコードが挿入された場合、これらのトリガが実行される順序は保証されません。
  • 部分的な完了が許可されている場合に DML コールが行われると、最初の試行でいくつかのレコードがエラーになったときに、レコードの保存を 2 回以上試行できます。たとえば、ユーザ入力規則に違反した場合、レコードにエラーが発生することがあります。トリガは最初の試行時に実行され、その後の試行時に再び実行されます。これらのトリガの呼び出しは同じトランザクションの一部のため、トリガがアクセスする静的クラス変数はリセットされません。DML コールは、Database DML メソッドの allOrNone パラメータが false に設定されている場合、またはデフォルト設定で SOAP API をコールした場合に、部分的完了を許可します。詳細は、「一括 DML 例外処理」を参照してください。
  • 組織で取引先責任者-to-複数取引先を使用している場合、非公開の取引先責任者を挿入すると必ず AccountContactRelation が作成され、取引先責任者がデータベースに保存された (ステップ 6) 直後にその入力規則、データベースの挿入、トリガが実行されます。取引先責任者の主取引先を変更した場合は、AccountContactRelation が作成または編集されることがあり、取引先責任者がデータベースに保存された (ステップ 6) 直後に AccountContactRelation の入力規則、データベースの変更、トリガが実行されます。
  • before トリガを使用して商談レコードの [フェーズ] および [売上予測分類] を設定する場合、次のように動作します。
    • [フェーズ] および [売上予測分類] を設定すると、商談レコードにはこれらの正確な値が含まれます。
    • [フェーズ] を設定して [売上予測分類] を設定しない場合、商談レコードの [売上予測分類] はデフォルトで [フェーズ] トリガに関連付けられた値に設定されます。
    • [フェーズ] を API コールで指定した値またはユーザインターフェースから受信した値にリセットすると、[売上予測分類] 値も API コールまたはユーザインターフェースによって入力されます。[売上予測分類] に値を指定せず、入力された [フェーズ] がトリガ [フェーズ] とは異なる場合、[売上予測分類] はデフォルトで [フェーズ] に関連付けられた値に設定されます。トリガ [フェーズ] と入力された [フェーズ] が同じ場合、[売上予測分類] はデフォルト値に設定されません。
  • 商品に関連する商談をコピーする場合、次のイベントが順に発生します。
    1. 親商談が上記のイベントのリストに従って保存されます。
    2. 商談商品が上記のイベントのリストに従って保存されます。

    商談商品でエラーが発生した場合は、商談に戻ってエラーを修正してからコピーを行う必要があります。

    商談商品に固有のカスタム項目が含まれている場合は、それらをすべて null に設定してから商談をコピーする必要があります。

    メモ

  • Trigger.old には、トリガを起動した特定の更新より前のオブジェクトのバージョンが含まれます。ただし、これには例外があります。レコードが更新された後にワークフロールールの項目自動更新がトリガされた場合、最後の更新トリガの Trigger.old にはワークフローの更新直前のオブジェクトのバージョンは含まれず、最初の更新が実行される前のオブジェクトのバージョンが含まれます。たとえば、既存のレコードに初期値が 1 の数値項目があるとします。ユーザがこの項目を 10 に更新し、ワークフロールールの項目自動更新が起動されて項目が 11 に増えます。ワークフローの項目自動更新後に起動される更新トリガでは、Trigger.old から取得されるオブジェクトの項目値は、通常の場合のように 10 ではなく元の値の 1 になります。