ADVERTISEMENT

【Salesforce】レコードトリガーフローが想定と違う時の監査ログと履歴で追う方法

【Salesforce】レコードトリガーフローが想定と違う時の監査ログと履歴で追う方法
🛡️ 超解決

Salesforceのレコードトリガーフローは、レコードの作成・更新・削除を契機に自動処理を実行する便利な機能です。しかし、実際に動かしてみると「条件に合致しているはずなのに処理が実行されない」「意図しないタイミングで起動してしまう」「想定と異なる値が更新された」といった問題に遭遇することがあります。こうしたトラブルの原因を特定するには、Salesforceが提供する監査ログ(Audit Trail)やフローのバージョン履歴、デバッグログを活用することが重要です。本記事では、レコードトリガーフローが想定通りに動作しない場合に、どのログをどのように確認すれば原因を切り分けられるのか、具体的な手順と判断基準を解説します。システム管理者だけでなく、一般ユーザーが管理者に依頼する際のポイントも含め、実務に役立つ情報をまとめました。

【要点】この記事で確認すること

  • 最初に見る場所: フローのバージョン履歴(Flow Version History)と監査ログ(Audit Trail)の「フロー定義の変更」を確認します。
  • 切り分けの軸: 端末側の操作ミスか、フローの設計ミスか、Salesforceの標準機能の制限かを切り分けます。
  • 注意点: 監査ログはシステム管理者のみ参照可能です。一般ユーザーは参照できないため、管理者に依頼する必要があります。また、フローの実行結果はデバッグログでも追跡できますが、ログレベル設定が必要です。

ADVERTISEMENT

レコードトリガーフローが想定と違う場合の全体像

レコードトリガーフローが期待通りに動かない原因は、大きく分けて以下の3つに分類できます。

  • フロー定義の誤り: 条件式の記述ミス、参照関係の誤り、数式の誤りなど。
  • 実行環境の問題: 権限不足、プロファイル設定、共有ルール、トリガの起動順序など。
  • Salesforceの制限: ガバナ制限(1組織あたりのフロー実行数)、非同期実行のタイムラグ、プラットフォームイベントの遅延など。

これらの原因を特定するためには、まず「何が起きているのか」を客観的な証拠(ログ)に基づいて把握する必要があります。そのために、Salesforceが提供する監査ログと履歴を活用します。

代表的な「想定と違う」パターン

よくあるパターンとして、次のようなものがあります。

  • 条件を満たしているはずなのにフローが起動しない
  • フローは起動したが、更新処理が行われない
  • 同じレコードに何度もフローが実行されてしまう
  • 削除トリガでフローが動かない
  • 参照項目の値が正しく取得できない

これらのパターンに対して、それぞれ確認すべきログが異なります。次章以降で具体的な確認手順を説明します。

監査ログを使ってフロー実行を確認する手順

監査ログ(Audit Trail)は、組織内の設定変更や重要な操作を記録する機能です。フロー関連では、フローの有効化・無効化、バージョンの公開、削除などの操作が記録されます。以下の手順で確認できます。

  1. 「設定」→「クイック検索」ボックスに「監査ログ」と入力し、「監査ログ」を選択します。
  2. 「イベントタイプ」で「フロー定義の変更」を選択し、「検索」をクリックします。このとき、日付範囲を絞り込むと目的のイベントを見つけやすくなります。
  3. 表示された一覧で、「アクション」列に「有効化」「無効化」「公開」などの操作が表示されます。対象のフロー名を確認します。アクションが「公開」の場合、そのバージョンが有効になったことを示します。
  4. 「詳細」列の「表示」リンクをクリックすると、変更内容の詳細がポップアップで表示されます。例えば、条件式の変更や更新要素の追加・削除などが記録されています。
  5. 特に「公開」操作の日時を確認し、その後にフローの動作が変わったかどうかを比較します。もし問題が発生した日時と近い公開操作があれば、その変更が原因である可能性が高いです。

注意点として、監査ログはシステム管理者のみがアクセスできます。一般ユーザーの場合は管理者に依頼する必要があります。また、監査ログは過去半年分が保存されていますが、長期保存を有効にしている場合はさらに過去のデータも確認できます。

履歴関連オブジェクトの使い方

フローのバージョン履歴は、フロービルダーの「バージョン」タブから確認できます。過去のバージョンとの比較や、いつ誰が変更したかを追跡できます。

フローバージョン履歴の確認手順

  1. 設定からフローを開き、該当のフロー名をクリックします。
  2. フローの詳細ページで「バージョン」タブを選択します。
  3. 各バージョンの「最終更新日」や「最終更新者」を確認し、意図しない変更がないか調べます。
  4. バージョン番号をクリックすると、そのバージョンのフロー定義を表示できます。変更前後で条件式や更新処理に差異がないか比較します。
  5. もし複数のバージョンが同時に有効になっている場合は、最新バージョンのみを有効にすべきです。古いバージョンが意図せず有効になっていないか確認します。

また、フロー実行の履歴は「フローの実行履歴」レポートでも確認できますが、注意点として、レコードトリガーフローは自動的に実行履歴が保存されない場合があります。デバッグのために「フローの実行を保存」設定を有効にしておくことを推奨します。この設定は、フローの「詳細」タブにある「フローの実行を保存」チェックボックスで有効にできます。

状況別の比較表

以下の表は、代表的な「想定と違う」状況と、その際に確認すべきログ・履歴をまとめたものです。トラブルシューティングの際の参考にしてください。

症状 考えられる原因 確認するログ/履歴
フローが起動しない 条件式がfalse、レコードタイプ不一致、権限不足 デバッグログ、フロー実行履歴、条件式の見直し
フローは起動するが更新されない 更新処理の誤り、項目制御不可、ループ対策(再更新防止) フローバージョン履歴、監査ログ(変更履歴)、フィールド履歴追跡
フローが複数回実行される トリガ条件の重複、バージョンの重複有効化、再帰呼び出し 監査ログ(有効化履歴)、フローバージョン一覧、SOQLクエリ
削除トリガが動かない 削除トリガのサポートバージョン、権限、レコード削除ポリシー デバッグログ、監査ログ(フロー定義変更)、削除済みレコードの復元確認
参照項目の値が空になる 参照関係の取得漏れ、トリガのタイミング(Before/After) デバッグログ(変数値)、フローの「参照の取得」設定、SOQLクエリの確認

よくある失敗パターンと切り分けの具体例

ここでは、実際に遭遇しやすい失敗パターンをいくつか取り上げ、どのログでどのように切り分けるかを説明します。

パターン1: 条件を満たしているはずなのにフローが起動しない

例えば、「ステータスが’進行中’に変更されたらメールを送信する」というフローがあるとします。該当レコードを更新してもフローが起動しない場合、まずはデバッグログを有効にして実際の条件評価を確認します。デバッグログには、フローが評価されたかどうか、条件がtrue/falseのどちらだったかが記録されます。また、監査ログでフローが有効になっているか、最新バージョンが公開されているかを確認します。特に、バージョン管理を見落としがちで、古いバージョンが有効になっているケースがあります。

パターン2: フローは実行されたが更新処理が行われない

この場合、フローの更新処理に問題があります。監査ログでフロー定義の変更履歴を確認し、誰かが更新要素を削除していないかを調べます。また、フィールド履歴追跡を有効にしている項目であれば、該当レコードのフィールド履歴を開き、想定外の値変更がいつ行われたかを確認します。もし別のフローやワークフロールールが同時に動作している場合は、実行順序の問題も考えられます。

パターン3: 同じレコードに何度もフローが実行されてしまう

再帰実行が疑われる場合、監査ログでフローの有効化操作が重複していないかを確認します。また、フローバージョンで複数のバージョンが同時に有効になっていないかチェックします。設計上の問題として、更新トリガの中で同じレコードを更新すると、それが再度トリガを呼び出す無限ループに陥ることがあります。その場合は、条件に「以前の値と異なる」などのチェックを入れる必要があります。

管理者へ確認する情報

一般ユーザーがログにアクセスできない場合、管理者に依頼する際は以下の情報を伝えるとスムーズです。

  • 問題が発生した日時とレコードID
  • 想定した動作と実際の動作の違い
  • 関連するフローの名前とバージョン番号
  • すでに試した確認事項(例:権限、トリガ条件の見直し)
  • 「監査ログのフロー定義の変更」を確認してほしい旨

管理者は、監査ログに加えて、デバッグログの設定やフローの実行履歴の保存設定を一時的に有効にして、問題を再現することで原因を特定できます。

よくある質問

Q1: 監査ログが空で表示されるのはなぜですか?

監査ログに何も表示されない場合、フィルターの条件が厳しすぎるか、対象のイベントが存在しない可能性があります。日付範囲を広げてみるか、イベントタイプを「すべてのイベント」にして検索してみてください。また、監査ログの保存期間を過ぎている場合もあります。

Q2: デバッグログを有効にしてもフローのログが出ません。

デバッグログは、トレースフラグを設定したユーザーの操作に対してのみ記録されます。フローを実行するユーザー(多くの場合はシステム管理者または自動実行ユーザー)に対してトレースフラグを設定する必要があります。また、ログレベルで「フロー」を「FINEST」など詳細に設定してください。

Q3: フローの実行履歴が保存されていません。どうすればいいですか?

レコードトリガーフローはデフォルトでは実行履歴を保存しません。フローの「詳細設定」で「フローの実行を保存」を有効にすると、今後の実行履歴が保存されるようになります。過去の実行履歴を確認したい場合は、監査ログやデバッグログを参照してください。

Q4: フローのバージョンが複数あり、どれが有効かわかりません。

フローの詳細ページの「バージョン」タブで、各バージョンに「有効」というステータスが表示されます。有効なバージョンは通常1つだけです。もし複数表示されている場合は、最新バージョンのみを有効にし、他は無効化することをおすすめします。

まとめ

レコードトリガーフローが想定と違う動作をした場合、まずは落ち着いて監査ログとフローバージョン履歴を確認することが第一歩です。監査ログからはフローの有効化や変更のタイミングがわかり、バージョン履歴からは設計変更の影響を特定できます。また、デバッグログを活用すれば、条件評価や変数の値まで詳細に追跡できます。これらのログを組み合わせて原因を切り分けることで、無駄な修正を防ぎ、的確な対策を講じることができます。

最後に、日頃からフローのバージョン管理と監査ログの確認を習慣化しておくことをおすすめします。特に、複数の管理者が関わる環境では、誰がいつ何を変更したかを追跡できる体制を整えておくことがトラブル防止につながります。また、問題が発生した際の再現手順をドキュメント化しておくと、次回以降の対応がスムーズになるでしょう。


ADVERTISEMENT

この記事の監修者
✍️

超解決 第一編集部

疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。

ADVERTISEMENT