Salesforce のフローのエラーメールが届いたときの調べ方

エラーメールは誰に届くか

フローの実行が失敗すると、Salesforce からエラーメールが送られます。届く相手は、[設定] の [プロセスの自動化設定] にある「プロセスまたはフローエラーメールの送信先」で決まります。[1][2]

• プロセスまたはフローを最後に変更したユーザー：エラーが出たフローを最後に変更した人に届きます。[1][2]
• Apex 例外メールの受信者：[設定] の [Apex 例外メール] ページに登録したアドレスに届きます。[1][2]

最後に変更した人が辞めていたり、対応する立場でなかったりする場合は、Apex 例外メールの受信者へ切り替えると、決まった担当者に集められます。この設定を変えるには「アプリケーションのカスタマイズ」権限が要ります。[1]

メールには、ユーザーが入力した値を含め、フローが扱ったデータが載ります。転送や共有をするときは、中身を確かめてからにします。[1][2]

管理パッケージから入れたテンプレートでないフローでは、メールに要素ごとの詳細が載らず、インストールしたユーザーか Apex 例外メールの受信者に送られます。[4]

メールの中で見る所

フローが失敗すると、実行していた人の画面には「An unhandled fault has occurred in this flow」というメッセージが出ます。同時に、管理者側にはエラーメールが届き、失敗したインタビューが記録されます。[5]

メールを開いたら、次の 4 か所を順に見ます。[3]

• 1. エラーメッセージ：原因の説明です。「未対応の例外」「要素に失敗しました」や、入力の検証エラーなどの言葉を探します。[3]
• 2. フロー名とバージョン：どのフローの、どのバージョンで失敗したかが分かります。[3]
• 3. 要素の詳細：失敗した要素の API 参照名や表示ラベルが載ります。[3]
• 4. スタックトレース：込み入ったフローや Apex アクションを調べるときの手がかりです。[3]

変数の値の変化は「{!変数} (前の値) = 項目 (新しい値)」の形で書かれます。サブフローで失敗した場合、メールは親フローの作成者に届きますが、件名には呼び出された側のフロー名が入ります。[4]

要素の名前が「レコードを取得 1」のままだと、メールを読んでも場所が分かりません。公式のヘルプも、要素に意味の分かる表示ラベルと API 参照名を付けておくよう勧めています。[3]

失敗したフローインタビューとデバッグで確かめる

エラーメールにある「フローエラー: Flow Builder でエラーをデバッグするには、こちらをクリックしてください」のリンクを押すと、失敗した実行のデバッグの詳細を Flow Builder で開けます。このリンクは、一部のフロー種別のメールにだけ出ます。[3][5]

メールを見落とした場合は、オートメーションアプリケーションの [監視] タブで、失敗したフローインタビューの一覧と [エラーの詳細] を確かめられます。フロー名を開き、[開く] を押すと、同じくデバッグの詳細に進めます。この画面を見るには「フローの管理」権限が要ります。[8]

失敗したフローインタビューは、保存されてから最大 14 日で自動的に消えます。また、障害コネクタでエラーを処理した場合や、1 つのフローで 24 時間に 100 件を超えた場合などは保存されません（2026年10月時点）。[4]

原因の見当が付いたら、Flow Builder の [デバッグ] でサンプルの値を入れて動かし、どの要素で止まるかを見ます。自動起動フローとレコードトリガーフローは、組織でフローテストモード（ベータ）を有効にすると、テストモードでも試せます（2026年10月時点）。[3][6][17]

ロールバックモードを選ばずにデバッグすると、レコードの更新などが実際に行われ、後から取り消されません。削除の要素を含むフローは、無効なフローでも削除が動くため、特に注意します。[6][7]

原因の種類を見分ける

• 原因 1必須項目レコードの作成や更新で、必須の項目に値を入れていないと REQUIRED_FIELD_MISSING になります。エラーの詳細に出る項目の API 参照名を手がかりにします。[9]
• 原因 2入力規則・レコードタイプ入力規則で条件付きで必須になる項目や、レコードタイプごとに違う必須項目があると、あるレコードでは通り、別のレコードでは失敗します。[9]
• 原因 3入力値・条件変数や必須の入力パラメーターが空のまま、要素が動いた場合です。レコードトリガーフローでは、エントリ条件も合わせて見直します。[3]
• 原因 4権限・アクセス実行するユーザーによって結果が変わる場合は、権限やアクセスの問題を疑い、別のユーザーとして試します。[3][15]
• 原因 5ガバナ制限1 つのトランザクションでの SOQL の回数や CPU 時間などの上限を超えると、トランザクション全体が取り消されます。CPU 時間の上限は、同じトランザクションの Apex トリガーや他のフローと分け合います。[10][11]

障害パスでエラーを扱う

レコードの作成や更新など、データベースを操作する要素は失敗することがあります。こうした要素に障害パス（障害コネクタ）を付けると、失敗したときに既定の動きの代わりに、障害パスの先の要素が動きます。[3][12]

公式のヘルプが勧める作り方は、次の 2 つです。[12]

• 1. 失敗しそうな要素から障害パスを引き、[メールを送信] アクションにつなぎます。本文に {!$Flow.FaultMessage} と主な変数の値を入れておくと、原因を追いやすくなります。[13]
• 2. 画面フローでは、障害パスの先に画面要素を置き、テキストテンプレートで分かりやすいメッセージを出します。既定のメッセージより、利用者が次に何をすればよいかを伝えられます。[14]

ただし、ガバナ制限を超えた場合は、障害パスを付けていてもトランザクション全体が取り消されます。障害パスは、制限の超過まで受け止める仕組みではありません。[11]

直すときの進め方

直す作業は、本番ではなく Sandbox で進めます。レコードトリガーフローは、デバッグでは常にロールバックモードで動き、フローの中だけを確かめる形になります。他のフローやトリガーと組み合わさった本当の動きは、Sandbox でデバッグを使わずに動かし、デバッグログで確かめます。[7]

別のユーザーとしてデバッグする機能は、Sandbox でだけ使えます。権限が原因かどうかを確かめるときに使います。[15]

Sandbox で有効にしたフローは、既定では本番に無効の状態でリリースされます。リリースした後に、新しいバージョンを本番で有効にし直します。[16]

直した後は、Flow Builder のデバッガーでもう一度試します。出たエラーと直し方は、チームで読める形で残しておきます。[3]