エラートリガー
指定した本番ワークフローが失敗したとき、別の処理フローを開始します。
Flow Error は、自動の本番実行が最終的に失敗した後、通知や障害記録に使います。元の実行の終了状態は変わりません。
上流フローを選ぶ
処理用フローに Flow Error を追加し、監視する公開済みフローを選択します。公開設定はフロー ID のリストです。
{
"op": "node.add", "as": "failure", "type": "error", "name": "Production failure",
"config": { "sourceFlowIds": ["UPSTREAM_FLOW_ID"] }
}
空のリストでは何も監視しません。自身、未公開、削除済みのフローは選択できません。対象を選択してから、処理フローを公開して有効化します。


- 入力
- 監視する公開済みの上流フローを選びます。サンプルの初期選択は空です。
- 想定される結果
- 対象となる上流の失敗で処理が始まります。元の実行は失敗状態を保持します。
- 実行前の準備
- 公開済みの上流フローを選択し、処理フローを公開して有効化してください。手動実行では Flow Error は起動しません。
起動条件
対象となる自動実行には Webhook、Schedule と、Gmail の新着メールなどポーリングで検出するアプリイベントが含まれます。最終失敗または結果不明で処理を開始できます。手動の Draft・Live 実行、成功、取消しでは起動しません。
失敗した 1 回の実行につき、購読中の処理フローごとに最大 1 回の処理実行を作成します。デプロイ先は配信予定を永続化し、受付前に処理フローの適格性を再確認します。処理フローの失敗から再帰的に別の処理は起動しません。
出力
workflow:元フローと固定された公開版・リビジョン。execution:元の実行と終了状態。error:コード、メッセージ、取得可能な失敗ノードや実行の識別情報。
ドラフトテストでは、実際に本番障害を起こさずに代表的な失敗データを渡せます。本番の配信は別途確認してください。
復旧を判断する
障害を処理しても、元の実行は再試行・修復されません。結果不明の場合、外部操作がすでに反映されている可能性があります。繰り返す前に外部システムを確認してください。ノード内の処理はエラーと再試行を参照してください。