承認フローをPower Automateで組むのは比較的簡単だが、現場に「定着させる」のは別の話だ。
本業でPower Automateの社内導入支援をしている立場から、承認フローの定着に失敗するパターンと、長く使われている設計の違いを整理しておく。
定着しない承認フローに共通するパターン
1. 承認者が「なぜここで止まっているか」を理解していない
フローを申請者側で設計すると、承認者がメール通知を受けても、背景が分からないまま「承認」か「却下」を選ぶ状態になりやすい。承認ボタンを押す行為が形式化し、「とりあえず承認」になってしまう。
対策：承認メール本文に判断に必要な情報を全て含める
✅ 申請内容の概要（誰が、何を、いつまでに）
✅ 前回の承認履歴（初回申請か否か）
✅ 却下時の理由入力フォームへの導線
2. モバイルからの承認を考慮していない
Teams通知やOutlookメールからの承認をPC前提で設計していると、外出中の承認者が「後でやろう」と後回しにしやすい。これがフロー滞留の主因になるケースが多い。
Power Automateのアダプティブカードは、TeamsモバイルアプリからもApprove/Rejectができる。承認操作の画面確認はPCとモバイル両方で必ず行うこと。
3. タイムアウト・エスカレーションを設計していない
承認者が長期不在のときの処理を入れていないと、フローが無期限に止まる。
最低限入れておくべきもの
・タイムアウト（例：72時間で自動リマインド、120時間でエスカレーション）
・代理承認者またはエスカレーション先の設定
・申請者への「承認待ち」状態の可視化
長く使われている設計に共通すること
承認フローの変更コストが低い
現場のルールは変わる。Excelベースのマスターデータを参照する設計にしておくと、承認者の変更・追加がコードを触らずに済む。
エラー時の連絡先が明確
フローが予期せず止まったときに、誰に連絡すればいいかがメール本文に書いてある。IT部門へのエスカレーション導線を最初から用意しておくと、問い合わせが激減する。
「ログが見える」安心感を提供している
SharePointリストに承認履歴を書き出しておくと、「あの申請、誰が承認したっけ」に答えられる。監査要件がある部門では特に重要。
承認フロー自体は数時間で組めるが、現場に定着させるまでには地味な設計の積み重ねが要る。技術的な実装より、「誰が使うか」「どこで詰まるか」を先に想像する時間の方が、後工程を減らせると感じている。
この辺りの設計思想はnoteでも詳しく書いている：Power Automateの承認フロー、現場に定着させるための考え方