松本典子の「はじめよう！Azure Logic Apps／Power Automateでノーコード／ローコード」 第48回

「備品購入」「経費申請」など、承認者やその数が異なる承認ルートをまとめて処理

Power Automateで「複数の承認ルート」対応の承認ワークフローを作ろう

3-6-1. 「いいえ」の場合：項目の取得

　次に条件分岐が「いいえ」の場合、つまり「申請の種類」が「経費申請」の場合のフローを作ります。

　選択するアクションや設定内容は、先ほど「はい」の場合（3-5-1.～3-5-3.）で示したものとほぼ同じです。以下では「はい」の場合と異なる部分のみ紹介します。

承認ルート「経費申請」

　SharePointリスト「ApproverList」から、承認ルート「経費申請承認」を取得します。検索窓に「SharePoint」と入力してコネクタをクリックし、アクションから「項目の取得」を選択します。

アクションの設定：項目の取得

　ここで設定する内容は「はい」の場合と同じですが、IDのみ「2」に変更します。このアクションにより、承認ルート「経費申請承認」の承認者情報を取得できました。

3-6-2. 「いいえ」の場合：開始して承認を待機

　「承認」コネクタの「開始して承認を待機」アクションを利用します。検索窓に「承認」と入力してコネクタをクリックし、アクションから「開始して承認を待機」を選択します。

アクションの設定：開始して承認を待機

　ここも設定する内容は「はい」とほぼ同じですが、「2-1. SharePointリストの準備」で作成した「ApproverList」では、承認ルート「経費申請承認」の承認者が3人でした。そこで「承認ステップ担当者」を3つに増やし、動的なコンテンツの「項目の取得」から「Approver01Email」～「Approver03Email」を設定しています。

3-6-3. 「いいえ」の場合：項目の更新

　最後に、SharePointリスト「EmployeeApplicationList」のステータスを変更する処理を追加します。

アクションの設定：項目の更新

　ステータス Valueは「完了」を選択します。

「はい」と「いいえ」のアクション設定の全体像

　「はい」の場合と「いいえ」の場合のアクションの全体像は、上図のような形になります。同じアクションを複数回利用するので、動的なコンテンツで選択する値に気をつけてください。

　以上でフローが完成しました。最後は忘れずに、フローに名前を付けて「保存」します。筆者は今回「承認リスト」というフロー名を付けて保存しました。

4. 実行結果

　フローが完成したので、さっそく試してみましょう。Microsoft Formsで作成した「従業員用承認フォーム」から、承認申請を入力して送信します。今回は、承認者が3人いる「経費申請」を申請してみました。

承認者への通知

　承認アクションで設定した承認者の順に、通知が自動的に出ます。「ステップ1」～「ステップ3」は自動で進み、承認者全員の承認処理が完了すると、申請者および承認者全員に、Microsoft Teamsで「承認結果」が通知されます。

　なお、承認者の誰か一人でも「拒否」するとフローは終了し、申請者および承認者全員にTeamsで「承認結果」が通知されます。

最後に

　今回は、複数の承認ルートがある承認ワークフローを作成しました。

　承認ルートをSharePointリストに書き出すかたちで設定しているため、承認者が変わった場合はSharePointリストの承認者を変更するだけで修正できます。一方で、承認者の人数が変わった場合は、「開始して承認を待機」アクションの「承認ステップ担当者」の数を修正する必要があります。そのため、複雑で承認者の数が多い承認ルートや、承認ルートそのものが多い場合は、運用管理が大変になるかもしれません。

　ここで考えていただきたいのが「承認ルートの最適化」です。そもそも承認ワークフローを作成したのは、業務を効率化するためです。現行の承認ルートが必要以上に複雑になっていたら、それそのものが効率化の妨げになります。ワークフローの作成をきっかけに、既存の業務のあり方を見直すことで、さらに効率的になるでしょう。