Power Automateの承認待ちがタイムアウトしたら、同じ申請をすぐ再送せず、flow runの状態と承認recordの状態を別に確認します。承認画面に依頼が残っていても、元のflowが回答を待ち続けているとは限りません。逆に、通知が見えなくても承認recordが作成済みの場合があります。
本稿はcloud flowの承認処理の診断・復旧設計です。実際の承認、取消・削除、再送、flow再実行、Dataverseの更新は実施していません。以下の対応表は架空例で、特定環境での復旧成功を示すものではありません。
目次
申請ID・承認ID・run IDを結び付ける
業務上の申請ID、approval ID、flow/run ID、申請内容のバージョン、作成時刻と期限を記録します。再申請があれば、旧依頼と新依頼を区別します。同じ件名のmailやTeams cardだけで、どの承認への回答かを決めないようにします。
表は横にスクロールできます
| 観察した状態 | 確認する対象 | まだ行わないこと |
|---|---|---|
| runがTimed out | 待機actionとrun開始時刻 | 全体を即再実行 |
| 承認一覧にPendingが残る | approval IDと待機run | 有効な依頼と断定 |
| cardだけ古い表示 | approvalとrunの実状態 | 重複承認を新規作成 |
| 承認済みなのに後続未完了 | 回答記録と失敗action | 承認結果の上書き |
受信mailの返信やcardの見た目だけで処理済みにせず、ownerが対象runと承認状態を照合します。logへ申請本文や個人情報を丸ごと複製せず、識別子と必要な状態だけを残します。
30日と28日の資料を、同じ期限として扱わない
cloud flowのlimits資料（新しいタブで開く）は、run durationを開始時から30日とし、承認待ち等も含み、期限後のpending stepがタイムアウトすると説明しています。一方、approvalsの既知問題（新しいタブで開く）は承認flowの待機が28日を超えると失敗し、approvalがaction centerへ残る場合を案内しています。
この二つを「承認は必ず30日待てる」とまとめません。実runの開始、承認作成、待機action、表示されたerrorと設定を確認します。独自に短く設定したtimeoutがある場合も分けます。残り時間は、mailを読んだ日時だけから計算しないようにします。
期限後に残ったapprovalへ回答できても、それだけで終了したrunが再開する根拠にはなりません。承認recordの整理と、業務処理の再開を別の作業として扱います。公式の既知問題には残存approvalの管理者等による削除もありますが、証跡を保存せず一括削除する復旧手順にはしません。
timeoutと、回答後に待機が止まる問題を分ける
Create an approvalとWait for an approvalを別actionにした構成では、作成から待機に入る間のタイミングも確認します。公式の既知問題には、waitへ到達する前にすぐ回答されたとき、待機が進まなくなる場合が記載されています。単に期限を延ばす前に、同じapproval IDか、作成と待機の間に何をしているかを見ます。
承認結果をloopで待つ設計なら、ApprovedだけでなくRejected、Canceled、custom responseなど、対象の終状態を扱えているかを確認します。拒否や取消を「まだ承認されていない」と読み替えて、永遠に待つ条件にしないようにします。正常回答のrunだけでなく、未回答・拒否・取消の経路も整理します。
後続の部分成功を読んで、再開単位を決める
承認待ちが失敗しても、その前の申請record作成や通知は済んでいる可能性があります。また、回答後に台帳更新だけ成功し、通知で失敗したrunもあります。runの再送ボタンを押す前に、外部systemと申請台帳の状態を確認します。
表は横にスクロールできます
| 現在の事実 | 復旧で決めること | 二重処理の防止 |
|---|---|---|
| 元run終了・未承認 | 再申請するか担当者判断 | 旧依頼を明示的に扱う |
| 回答済み・業務未反映 | 有効な回答と内容バージョンを確認 | 元の回答根拠を保持 |
| 台帳更新済み・通知失敗 | 通知だけ再開可能か | 更新を繰り返さない |
| 外部処理の結果不明 | 識別子で状態を読み戻す | 不明を未実施と決めない |
期限切れ後の再承認では、申請内容が変わっていないかも確認します。旧バージョンへの同意を、新しい金額・対象・条件へ自動で転用しません。新しいapprovalを作る判断になった場合は、旧IDとの関係を残し、利用者がどちらへ回答すべきかを明確にします。
長く待つ業務は、run寿命と業務状態を分ける
長期申請を一つの実行中runだけへ預けるより、申請ID、内容バージョン、状態、担当者、期限、承認ID、処理済みstepを永続的に記録する設計を検討します。回答受領と後続処理を分ける場合は、二重通知や遅延回答、取消後の回答をどの状態遷移で拒否・保留するかを決めます。
これは業務設計の例で、Dataverse等のtableを直接書き換えれば復旧できるという製品手順ではありません。connectorの対応action、必要なlicense、組織の運用方式を確認し、承認者の意思決定をAIで代行しない構成にします。
再テストは四つの結果で確認する
許可された検証環境で、期限内の承認、拒否・取消、未回答によるtimeout、旧依頼への遅延回答を分けて確認します。各条件で、申請台帳、approval、run、外部更新の状態が矛盾せず、同じ業務処理が二重に進まないことを合格条件にします。
変更前のflow定義と状態対応表を保存し、問題があれば今回の差分を戻します。戻しても送信済み依頼や外部更新は残るため、残ったrecordをどう扱うかは別に確認します。完了記録には、失敗した待機段階、採用した回答根拠、再開した範囲、残存依頼、未確認の経路を残します。