結論：まずこれだけ覚える
障害コネクタ（フォールトパス）は、フロー要素が実行エラーになったときだけ進む例外処理の経路です。画面フローでは、障害パスの先に画面を配置して、ユーザーへ原因や対処方法を案内できます。障害パス内に通知やログ作成を配置でき、現在のトランザクションの保留中変更を取り消す必要がある場合は［レコードをロールバック］要素を使用します。 障害パスを設定しないままフローが失敗すると、実行ユーザーには「An unhandled fault has occurred in this flow」という一般的なエラーが表示され、フローを続行できません。
障害コネクタ（フォールトパス）とは
コネクタは、フローが実行時に進む経路を定義する接続線です。障害コネクタは、接続元の要素でエラーが発生した場合に実行する次の要素を指定します。 Salesforce公式Trailheadでは、次の要素に障害パスを追加できると説明されています。
- レコードを取得
- レコードを作成
- レコードを更新
- レコードを削除
- アクション 通常の経路は処理が成功した場合に進み、障害パスは処理が失敗した場合にだけ進みます。
障害パスを設定しない場合
処理されない障害が発生すると、実行ユーザーには一般的なエラーメッセージが表示され、フローは停止します。Salesforceは失敗したフローインタビューを作成し、通常はフローを最後に変更した管理者またはApex例外メール受信者へ詳細なエラーメールを送ります。
$Flow.FaultMessageは、障害パス内で参照できる詳細なエラーメッセージです。障害パスを設定しない場合に、この技術的な内容がそのまま利用者へ表示されるという意味ではありません。
画面フローでユーザーへ案内する
画面を含められる配布方法の画面フローでは、障害パスの先に［画面］要素を配置できます。表示内容には、次の情報を含めます。
- 処理できなかったこと
- ユーザーが確認または修正すべき内容
- 再実行の前に必要な操作
- 必要に応じて問い合わせ先や受付番号
たとえば、取引先の必須情報が不足して更新に失敗した場合は、「取引先の必要項目を入力してから、もう一度実行してください」と案内します。
$Flow.FaultMessageは調査に役立ちますが、技術的な内容を含むことがあります。エンドユーザー向けには分かりやすい説明を表示し、詳細メッセージは管理者通知やログへ含める設計が基本です。社内利用で詳細をユーザーに提示する必要がある場合は、目的を明確にして使用します。
実装の流れ
- Flow Builderで、失敗する可能性がある要素を特定する。
- 対象要素から障害パスを追加する。
- 画面フローでは、障害パスの先に［画面］要素を配置し、原因と対処方法を表示する。
- 必要に応じて、画面より前に管理者通知、ケース作成、ログ作成などの要素を配置する。
$Flow.FaultMessageや入力値など、調査に必要な情報を通知またはログへ含める。- 正常系と障害系の両方をデバッグし、対象ユーザーの権限でもテストする。 ユーザーがエラー画面でブラウザを閉じる可能性があるため、通知やログ作成など必ず実行したい処理は、エラー画面より前に配置します。
障害パスとロールバック
障害パスは、エラー後の処理経路を定義する機能です。障害パスへ進んだだけでは、現在のトランザクションで保留中のレコード変更が必ず取り消されるわけではありません。 画面フローで現在のトランザクションの保留中変更を取り消す必要がある場合は、障害パスに［レコードをロールバック］要素を配置し、その後にエラー画面を表示します。 ［レコードをロールバック］が取り消せるのは現在のトランザクション内の変更だけです。画面要素が実行されると既存のトランザクションが終了し、新しいトランザクションが始まるため、前の画面より前に完了したトランザクションの変更は、後の障害パスから取り消せません。
よくある誤解
障害パスは入力チェックの代わりになる
障害パスは実行エラーへの対応です。必須値の不足など事前に判定できる条件は、画面の必須設定や［決定］要素で先に確認すると、エラーを発生させずに案内できます。障害パスと事前チェックは併用します。
エラー画面を表示すれば管理者への記録も残る
障害パスでエラーを処理した場合、未処理の障害とは動作が異なり、期待する形式のエラーメールや失敗インタビューが必ず残るとは限りません。必要な通知やログは障害パス内で明示的に設計します。
障害パスを設定するとすべての変更が自動的に元に戻る
自動的な全変更の取り消しを保証する機能ではありません。トランザクション境界を確認し、必要な場合は［レコードをロールバック］を使用します。
要件別の使い分け
| 要件 | 代表的な対処 |
|---|---|
| 画面フローで原因と修正方法を説明する | 障害パス＋［画面］ |
| Salesforceが返した詳細を確認する | $Flow.FaultMessage |
| 画面フローで途中までの変更も取り消す | 障害パス＋［レコードをロールバック］ |
| レコードトリガーフローで独自エラーを返して変更を阻止する | ［カスタムエラー］要素 |
| 入力不足を実行前に防ぐ | 画面入力の必須化、［決定］要素による事前チェック |
試験での判別ポイント
- 「画面フローのエラーが分かりにくい」「原因と直し方を利用者へ示したい」なら、障害コネクタから画面へ進む構成を選ぶ。
- 「エラーを隠す」「検証ルールを削除する」だけでは、原因やデータ品質の問題を解決しない。
- 障害パスは例外処理、［決定］要素は事前に判定できる条件分岐と整理する。
- ロールバックが要件に含まれる場合は、障害パスだけでなくトランザクションと［レコードをロールバック］を確認する。
出典（Salesforce公式）
- Default Flow Error Handling — 未処理の障害が発生した場合に、実行ユーザーへ一般的なエラーが表示され、フローを続行できず、管理者へ詳細な障害メールが送信される既定動作を裏付けます。
- Customize What Happens When a Flow Fails — 失敗しうる要素へ障害パスを追加して既定のエラー処理を変更できること、画面を含められる配布方法で利用者向けメッセージを表示する推奨事項を裏付けます。
- Handle Flow Errors with Fault Paths — 障害パスがエラー時だけ実行される副次的な経路であること、レコード取得・作成・更新・削除・アクションに追加できること、および
$Flow.FaultMessageの使用方法を裏付けます。 - Other Examples of Error Handling in Flows — 障害パスから訂正用画面を表示する方法、詳細エラーの表示、ケース作成などのエラー処理例を裏付けます。
- Roll Back Pending Record Changes When a Flow Element Fails at Run Time — 画面フローの障害パスで［レコードをロールバック］を使用し、現在のトランザクションの保留中変更を取り消す動作を裏付けます。
- How Flows Run in Transactions — 画面要素が既存トランザクションを終了して新しいトランザクションを開始すること、およびトランザクション境界の考え方を裏付けます。