【Power Automate】承認者を部署ごとに変えたい場合の設計手順

Power Automateで承認フローを作成する際、申請内容に応じて承認者を変えたいケースは少なくありません。特に、部署ごとに承認者が異なる場合は、フローの中で動的に承認者を指定する設計が必要です。本記事では、SharePointリスト、Azure AD、Dataverseという3つの代表的な方法を比較し、具体的な手順や失敗を防ぐポイントを解説します。

承認者を部署ごとに変えるための3つの設計方法

方法1:SharePointリストで承認者マスタを管理する

SharePointリストに部署名と承認者の対応表を作成し、フローからそのリストを参照する方法です。以下の手順で設定します。

1. SharePoint Onlineで「承認者マスタ」という名前のリストを作成します。列として「部署名」(単一行テキスト)、「承認者メール」(人物またはメール列)を追加します。
2. 各部署の承認者を登録します。リストの権限は、フローを実行するサービスアカウントに少なくとも読み取りアクセスを付与します。
3. Power Automateで承認フローを新規作成し、トリガー(例:新しい承認要求が送信されたとき)を設定します。
4. アクション「SharePoint リストの取得」を使い、先ほど作成したリストからすべてのアイテムを取得します。
5. 「条件」アクションまたは「フィルター配列」アクションで、申請データの部署名とリストの部署名が一致する行を抽出します。
6. 抽出した行の承認者メールを変数に格納し、「承認」アクションの割り当て先にその変数を指定します。

この方法は、Power Automateの標準コネクタだけで完結するため、他のシステムへの依存が少ない点がメリットです。一方、リストの更新が手動になるため、部署変更や承認者の交代があった場合にリスト管理が煩雑になりがちです。

方法2:Azure ADのユーザー属性と動的グループを利用する

Azure ADにユーザーの部署属性(Department)が正しく設定されていれば、その属性をもとに承認者を動的に決定できます。以下の手順で設計します。

1. Azure AD管理センターで、各ユーザーの「部署」フィールドが正しく入力されていることを確認します。管理者に依頼して、必要に応じて一括更新してもらいます。
2. Power Automateで「ユーザーの取得(V2)」アクションを使い、申請者のユーザーオブジェクトを取得します。このとき、フィルタークエリに申請者のメールアドレスやユーザーIDを指定します。
3. アクションの出力から部署属性(Department)を取得します。
4. 「条件」アクションで部署に応じて承認者のメールアドレスを指定するか、「動的グループ」を利用する場合はグループのメンバー一覧を取得します。
5. 動的グループを使う場合、Azure ADに「部署別承認者グループ」を作成し、メンバーシップルールに「user.department -eq “部署名”」を設定します。フローでは「グループメンバーの取得」アクションでグループメンバーを取得し、承認者に割り当てます。

この方法は、Azure ADの属性が最新であれば管理が自動化されやすいメリットがあります。ただし、動的グループの反映には時間差がある点や、部門管理者が自分で承認者を変更できないデメリットがあります。

方法3:Dataverseを使う(Microsoft 365環境向け)

Dataverse(旧Common Data Service)はPower Platformの統合データベースです。承認者マスタをテーブルとして作成し、Power Automateから参照します。

1. Power Appsの「データ」メニューから新しいテーブルを作成します。列として「部署」(テキスト)、「承認者」(ユーザー)を追加します。
2. 承認者マスタのデータを直接入力するか、Power AutomateやPower Appsを使って管理フォームを作ります。
3. フローで「Dataverseの行の一覧表示」アクションを使い、テーブルから該当する部署の行を取得します。
4. 取得した行の「承認者」列のユーザー値を承認アクションに渡します。

Dataverseの利点は、データのリレーションやセキュリティ設定が強力で、部門ごとに編集権限を細かく設定できることです。ただし、Dataverse環境を用意するには管理者の設定が必要であり、ライセンスにも注意が必要です。

3つの設計方法を比較する

比較項目	SharePointリスト	Azure AD動的グループ	Dataverse
**管理の容易さ**	リストを手動更新する必要あり。やや面倒。	属性が自動反映されれば管理は容易。ただし反映に時間差あり。	テーブルなので柔軟だが、環境設定に管理者作業が必要。
**動的な変更**	リスト更新後すぐフローに反映。	最大24時間の遅延が発生する場合がある。	データ更新後即反映(キャッシュ依存あり)。
**必要なライセンス**	Power Automate無料プランでも可能(ただし実行回数制限あり)。	Azure AD P1以上(動的グループ利用の場合)。通常の属性取得は無料。	Dataverseの容量が必要。有償プランが多い。
**権限設定**	リストのアクセス許可を個別設定可能。	グループ単位の権限は設定できるが、属性ベースのため柔軟性に欠ける。	行レベルセキュリティが可能で非常に細かい制御ができる。

よくある失敗パターンとその対策

設計時にありがちな失敗を事前に把握しておきましょう。

• 部署名の不一致:申請フォームの部署入力欄とリスト/属性の値が完全一致していないと、承認者が見つかりません。対策として、入力値をトリミングしたり、どちらかに合わせるルールを徹底します。
• 権限不足でフローが失敗:SharePointリストやAzure ADの読み取り権限がないとアクションがエラーになります。フロー用のサービスアカウントに適切な権限を付与してください。
• 承認者が複数いる場合の意図しない割り当て:リストから複数行取得した場合、そのまま承認アクションに渡すと最初の一人だけに通知されることがあります。フィルターで絞り込むか、承認者配列を明示的に指定する必要があります。
• 動的グループの反映遅延を見落とす:承認者を変更した直後にフローが動くと、古いグループメンバーが引き継がれる可能性があります。変更は時間に余裕をもって行い、フローに「待機」アクションを入れることも検討します。

管理者に依頼すべき設定内容

Power Automateの設計だけでは解決できない部分は、管理者に以下の設定を依頼する必要があります。

• Azure ADのユーザー属性(部署)の整備:全社員のDepartment属性を正確に入力してもらいます。動的グループを活用する場合は、グループの作成とメンバーシップルールの設定も依頼します。
• SharePointリストのアクセス権:フローを実行するサービスアカウント(またはフロー所有者)に、リストの読み取り権限を付与します。
• Dataverse環境の用意(必要な場合):Power Platform管理センターで環境を作成し、ライセンスを割り当てます。また、テーブルの作成権限をフロー作成者に委任してもらいます。
• フローの共有アクセス許可:承認フローを他ユーザーが編集できるようにする場合、管理者にフローを共有してもらう必要があります。

よくある質問

Q1:承認者を部署ごとに動的に設定するには、どの方法が最も簡単ですか?
A:SharePointリストを使う方法が、特別な管理者権限が不要で導入しやすいです。ただし、リストの更新が手間になるため、部署数が少ない場合や頻繁に変更がない場合に向いています。

Q2:承認者が複数いる部署では、同時に全員に通知したいです。どうすればよいですか?
A:承認アクションの割り当て先に複数のメールアドレスを配列で指定すると、全員に通知されます。ただし、承認フローの種類(一人承認、全員承認)に応じて動作が変わるため、要件に合わせて調整してください。

Q3:Azure ADの動的グループの反映に時間がかかるのはなぜですか?
A:Azure ADの動的グループのメンバーシップ評価は非同期で行われ、最長で24時間の遅延が発生することがあります。リアルタイム性が求められる場合は、Azure ADの属性を直接参照する方法やSharePointリストの利用を検討してください。

Q4:部署外のユーザーが申請した場合のエラーハンドリングはどうすればいいですか?
A:条件分岐で該当する部署がない場合、フロー内でエラーアクションを設け、申請者に「承認者が見つかりませんでした」と通知するように設計します。また、管理者用の通知を追加すると運用がスムーズです。

まとめ

Power Automateで承認者を部署ごとに変える設計方法には、SharePointリスト、Azure AD属性/動的グループ、Dataverseの3つがあります。導入のしやすさ、管理の手間、リアルタイム性などを比較し、自社の環境や運用ルールに合った方式を選んでください。いずれの方法でも、部署情報の正確性と権限設定が成功の鍵です。本記事の手順を参考に、まずは小規模なフローでテストしてから本番展開することをおすすめします。