Power Automate承認フローの作り方

結論：承認メールより先に「申請の記録」と「承認後の更新先」を決める

「申請が来たら上司へメールする」。ここまでは簡単に見えます。しかし、申請者はどこで結果を確認し、承認コメントはどこへ残し、誰が未処理を把握するのでしょうか。

最初の1本なら、Microsoft Lists／SharePoint Listの申請 → 承認者に依頼 → 承認・却下 → 申請リストの状態更新 → 申請者に通知という流れを分解します。承認メールを送っただけでは、承認業務は終わりません。受信箱が承認台帳を兼ねる運用は、だいたい後で誰かが検索します。

1. まず、扱う項目と権限を決める

編集用の架空例として「備品購入申請」を考えます。申請の保存場所はMicrosoft Lists（内部的にはSharePointリスト）の1リストです。

これらの列名・運用項目は編集部の設計例でありMicrosoftの必須テンプレートではありません。Microsoft LearnではMicrosoft Listsに申請項目を作成し、リストの新規アイテムをきっかけに承認処理を始める公式例を説明しています。

一次資料：Microsoft Listsの承認フロー（公式）

2. Triggerは「新規作成」を選んで無限ループを避ける

Power AutomateのAutomated cloud flowで、SharePointのWhen an item is createdをTriggerにする構成が公式チュートリアルにあります。

1. Power Automateで新規の自動化クラウドフローを作成。
2. SharePointのリスト用Triggerを選び、対象のSite AddressとList Nameを指定。
3. 指定したリストでダミー申請を作り、想定したアイテムだけがTriggerに現れることを確認。
4. 必要な接続権限を確認して次のApprovalsへ進む。

「作成または変更」をTriggerにして、フロー自身が同じリストを更新する設計は、更新のたびに再実行し得るため注意が必要です。新規申請だけを扱う場合は「新規作成」の範囲から始める方が構造を理解しやすくなります。

これはトリガー選定に関する編集判断であり、すべての更新トリガーが無限ループになるという意味ではありません。

一次資料：Create and test an approval workflow

初回利用の前提：Microsoft公式はApprovalsの初回利用について、有効なFlow作成ライセンスとDataverseデータベースなどの条件を説明しています。「Microsoft 365契約だけあれば承認機能が自動的に使える」とは判断しません。組織のテナント管理者へDataverse・DLP・接続権限を確認します。 Microsoft Learn Approvals prerequisites

3. Approvals：誰が承認するか、いつ完了するかを決める

承認処理ではStart and wait for an approvalアクションを使用する公式例があります。このアクションは申請情報を承認者へ届け、その応答を待ちます。

ここで設定すべき条件は少なくとも次の3点です。

• 承認者：役職名でなく実際に受け取るユーザー／グループ。代理・不在時の扱いも先に決める。
• 承認方式：First to respond（誰か1名の応答で確定）なのか、Everyone must approve（全員承認が必要）なのかを業務ルールで選ぶ。
• 処理にかかる時間：期限切れや長期滞留を放置しない。承認者を増やすと運用例外も増えます。

Microsoft Learnでは、複数承認者が必要な場合「全員承認」と「最初の応答で確定」の挙動を分けて説明しています。単なるメールのCCとは意味が違います。

設計例：少額備品は直属の上長1名、一定金額以上は部門責任者も承認、といった金額分岐を採用する場合は、利用者の実際の社内稟議ルールを優先します。閾値は組織ごとに異なり、製品仕様ではありません。

一次資料：Modern approvals / All assigned must approve

4. 承認／却下後はリストを更新し、申請者に返す

承認されたら申請リストの該当Itemを「承認」に更新し、承認日と承認コメントを保存。却下されたら「却下」に更新し、理由と通知先を記録します。

Flowの概念上は次のようになります。

Microsoft Lists: 申請作成
  → SharePoint Trigger: When an item is created
  → Approvals: Start and wait for an approval
  → Condition: OutcomeがApproveか？
       ├─ Yes → SharePoint Update item: 承認 / 申請者へ通知
       └─ No  → SharePoint Update item: 却下 / 申請者へ通知

Microsoft Learnの公式チュートリアルも、承認・却下に応じてSharePoint Update itemでリストの内容を更新し、通知メールを送る構成を案内しています。

要注意：Update itemではSite Address、List Name、対象のItem Idなどを適切に指定します。別の申請を誤更新しないことが、目に見えるメール以上に重要です。

一次資料：Microsoft Learn 承認の作成とテスト

5. 動かない時は5か所を切り分ける

これは公式機能を前提にした編集部の診断順序であり、各現象を実機で再現した検証結果ではありません。試験時は架空の申請3件程度を作り、承認・却下・未応答をそれぞれ確認する方法を提案します。

6. Microsoft 365を持っていれば追加費用ゼロ、とは限らない

Microsoft 365の利用契約は環境によって異なります。SharePoint／Outlookへのアクセス権、Power Automateのライセンス、コネクタ区分、テナント管理者のDLPポリシー、Approvals機能の利用条件を確認してください。

• 「Microsoft 365に含まれる」という一般論だけで、全員が作成・実行できると判断しない。
• テナントで使える機能でも、チームの共有／保守担当／退職時のOwner変更が残る。
• 承認待ちが長くなる業務は、実行の持続期間・再送・期限切れ時の処理まで決める。

料金やUser/Processライセンスの全体比較はA04 Power Automateとは？へ譲り、この記事では承認業務の流れが成立するかだけを扱います。

一次資料：Microsoft Learn Approvals

7. 実務で使う前の最終チェック

• 申請リストと承認結果を同じIDで結びつけられるか
• 承認権限とリスト閲覧権限を分けているか
• 承認・却下それぞれの分岐先で結果を保存するか
• 不在者、期限切れ、同時承認、取り消しの扱いを決めたか
• Flow所有者が休暇・異動・退職した場合の対応担当を決めたか
• 申請者はメールだけでなくListから現状を追えるか

承認の速さだけを追うと、誰が何を承認したか分からなくなることがあります。自動化の成果はメールの件数より、後から説明できる記録で測りたいところです。

まだ調べますか？

• Power Automateとは？ — 導入と権限・ライセンス
• Make vs Power Automate — Microsoft中心かSaaS横断か
• n8n vs Power Automate — Self-hostや高度な分岐が主目的なら

判断の出口： 標準のMicrosoft 365環境で扱える承認を始め、外部連携やRPAが必要になった段階でライセンスと運用責任を再評価します。

一次資料／区分

• Microsoft Learn: Microsoft Lists承認
• Microsoft Learn: 承認ワークフローの作成・テスト
• Microsoft Learn: 複数承認者
• Microsoft Learn: SharePoint listメール通知

FACT：SharePoint新規アイテム起点、Approvals、承認/却下の分岐、Update item、複数承認方式。

EDITORIAL：備品購入シナリオ、List列構成、トラブル切り分け、運用・権限チェック。