Power Automate の承認フローを Forms や Teams で試してみたけど、申請履歴の管理が難しいと感じたことはありませんか。SharePoint リストをデータソースにすれば、ステータスの追跡・証跡管理・催促の仕組みまで一気に整えることができます。
なぜリスト型承認フローが選ばれるのか
承認フローには大きく2つの設計パターンがあります。Microsoft Forms をトリガーにする方法と、SharePoint リストの項目作成をトリガーにする方法です。前者は手軽に始められる反面、申請状況をあとから確認しようとするとExcel台帳を手動で見に行かなければなりません。一方、後者はリスト自体が台帳を兼ねるため、承認担当者が現在どの案件が止まっているかを一覧で把握できます。
私の会社でも最初は Forms 型で運用していましたが、月に30〜40件の申請が走るようになったタイミングであの申請、今どこにあるの？という問い合わせが増えました。リスト型に切り替えてからは、申請者も承認者もリストを見れば状況がわかるようになり、問い合わせがほぼゼロになりました。申請件数が10件を超えてくるあたりで、リスト型への移行を真剣に考えることをおすすめします。
Power Automateの承認フロー全体の設計思想については承認フロー完全ガイドでまとめていますので、あわせて参照してください。
ステータス列の設計
リスト型承認フローの核心は、ステータス列の設計にあります。列の型は選択肢にし、以下の4つの値を用意するのが基本パターンです。
- 未申請
- 承認待ち
- 承認済み
- 却下
フローの流れとしては、申請者がリスト項目を新規作成した時点でステータスが「未申請」になっています。フローが起動して承認アクションが送信されると「承認待ち」に更新し、承認者が回答したら結果に応じて「承認済み」か「却下」に切り替えます。この更新には SharePoint コネクタの項目の更新（Update item）アクションを使います。
ポイントは、フローの開始して承認を待機するアクションの前後それぞれに項目の更新を入れることです。前の更新でステータスを「承認待ち」にし、後の更新でステータスを結果に応じて分岐させます。SharePoint リストへの基本的な書き込み操作についてはSharePointリストのCRUD操作の基本を参考にしてください。
フロートリガーの設定：無駄な起動を防ぐ
SharePoint リストのトリガーを「項目が作成されたとき」に設定するだけでは、列の更新のたびにフローが動いてしまう場合があります。「項目が作成または変更されたとき」を使う場合は、トリガー条件を設定して、ステータスが「未申請」のときだけフローが走るように絞り込む必要があります。
トリガー条件の式は以下のようになります。
@equals(triggerBody()?['Status']?['Value'], '未申請')この設定を入れることで、承認結果の書き戻し処理（ステータスを承認済みに更新する処理）によってフローが再起動してしまうループを防げます。トリガー条件の詳しい使い方はトリガー条件とフィルタークエリの解説記事で取り上げています。
添付ファイルの扱いと承認依頼の詳細リンク
稟議書や見積書など、添付ファイルを伴う申請フローでは、承認者が依頼メッセージを受け取った時点でファイルを確認できる状態にしておくことが大切です。承認アクションの詳細欄に SharePoint リスト項目のURLを差し込む方法が最もシンプルです。
動的コンテンツから項目へのリンクを選ぶと、承認者がクリックすれば直接リスト項目のページに飛べます。そのページから添付ファイルを開く流れです。詳細欄に直接ファイルを添付する方法もありますが、ファイルサイズが大きいと承認メールが届かない場合があるため、リンク方式のほうが安定します。
承認依頼の詳細欄には申請内容のサマリーも入れておくと承認者の判断が速くなります。例えば次のような文字列を作成（Compose）アクションで組み立てて、詳細欄に渡します。
申請者：@{triggerBody()?['Author']?['DisplayName']}
申請内容：@{triggerBody()?['Title']}
申請日：@{formatDateTime(triggerBody()?['Created'], 'yyyy/MM/dd')}
リンク：@{triggerBody()?['{Link}']}
催促（フォローアップ）機能の実装
承認者が応答しないケースは必ず発生します。特に役員や部長クラスが承認者になっている場合、メールやTeamsの通知が埋もれてしまうことが多い。こういった状況に備えて、申請者が自分でプッシュできる催促の仕組みを用意しておくと運用がスムーズになります。
実装方法は2段階に分けて考えます。まず1つ目は、承認アクションのリマインダー設定を使う方法です。承認アクションの詳細オプションに承認期限とリマインダーを送信の設定があり、指定した日時を過ぎても未回答の場合に自動でリマインダーメールを送れます。追加のフロー作成は不要なので、まずはこちらを使うことをおすすめします。
2つ目は、申請者が手動で催促できるボタンをPower Apps上に設置する方法です。申請者がリスト項目を選択して催促するボタンを押すと、別途作成した催促フローが起動して承認者にTeamsメッセージを送る、というパターンです。この場合、ステータスが承認待ちの項目のみボタンが押せるよう、ユーザー別フィルターの設計と組み合わせてUIを制御すると完成度が上がります。
取り下げ（キャンセル）機能の考え方
申請を間違えた場合に申請者自身が取り下げられる仕組みも重要です。Power Automate のフローはいったん開始して承認を待機するに入ると、外部から強制停止する手段がほぼありません。そのため取り下げ機能はフローを止めるのではなく、承認アクションが完了した後、キャンセルフラグを確認して処理を分岐させる設計にするのが現実的です。
具体的な手順としては、まずリストに「取り下げ（YesNo型）」列を追加します。申請者がこの列をオンにすると、承認担当者に取り下げの旨を通知する別フローが起動します。本フローでは承認待ちに入った後に取り下げ列がTrueかどうかをチェックする条件分岐を追加しておき、Trueだった場合はステータスを取り下げに更新して処理を終了します。
取り下げのステータス値は最初の設計に含めておくと後から変更しなくて済みます。選択肢に取り下げを追加するのを忘れがちなので注意してください。私はこれを後から追加して、既存フローの条件式を全部書き直す羽目になったことがあります。設計段階でひと手間かけておくと、運用フェーズで楽になります。
Power Apps 連携でUIをリッチにする展望
SharePoint リストとフローの組み合わせができあがったら、次のステップとして Power Apps でフロントエンドのUIを作ることが多いです。リストを直接開いて入力・確認するより、専用アプリのほうが操作ミスが減り、申請件数が増えても管理しやすくなります。
アプリ側では、自分の申請のみ表示、承認待ち案件だけ赤くハイライト、ステータス別にタブを切り替えるといったUIが作りやすくなります。Power Apps でのユーザー別フィルタリングの実装については、別記事で詳しく取り上げています。
承認フローはフロー単体で完結させず、Power Apps・SharePoint・Power Automate の3つをセットで設計することで、申請から承認・記録・通知まで一気通貫のワークフローが完成します。まずはシンプルな1ステップ承認から始めて、運用しながら催促や取り下げ機能を追加していくのが現実的な進め方です。市民開発はこういった地道な積み重ねで完成度が上がっていくものです。
