PowerAppsとPower Automateで代理承認機能を実装する方法（予約機能付き）

PowerApps + Power Automateを使って承認機能を運用されている企業様は一定数いらっしゃるかと思います。そして、その際、代理承認機能をどうするかという問題に頭を悩ませている担当者様や開発会社さんは結構多いのではないかなと思います。

もちろん、Power Automateで頑張って複雑な条件分岐を設定して実装することはできますが、導入後の保守や継続開発を考えるとできるだけシンプルに実装したいものです。なので、最初から承認者と副承認者の両方に承認依頼を飛ばすような仕組みにする、というのが落としどころになりがちです。

とはいえ、やっぱり担当者が長期休暇に入る場合などは期間を指定しておいて、あらかじめ代理承認者を登録できた方がいいですよね、ということで、なんだかんだで代理承認機能の実装が必要となることがあります。

・・ということで、本記事ではPowerAppsとPower Automateで意外と簡単に実装できる「代理承認機能（予約機能付き）」の開発方法について解説していきます。

ポイントはPower Automateをこねくり回して解決しようとせず承認ルートをマスタ化しておいてそっちでコントロールする、という点です。

今回はPowerApps (Dataverse)側で承認ルートを管理する前提で記載していますが、ExcelやSharepoint List、Google Spread Sheetなどで承認ルートを管理する運用でも同じような実装が可能です。

たとえば、以下のようにPowerApps (Dataverse) で承認ルートを管理する仕組みを作ったとします。

※今回はPowerApps (Dataverse)を例に説明しますが、計算式を指定できる仕組みであればExcelでもGoogle Spread SheetでもSharepoint Listなど、なんでもよいです。

ここで、代理承認機能を実装するときのポイントは、Power Automateの承認機能はメールアドレスで承認者を指定する仕様になっているという点です。したがって、メールアドレスのところを動的に代理承認者のものに差し替える仕組みを作ってしまえばそれでOKです。

ここからステップバイステップで解説していきます。

まずはDataverse標準のユーザーテーブルを拡張していきます。以下の手順で進めて行きます。

1. まずはDataverseのユーザーテーブルに標準で存在している既定電子メール(internalemailaddress)というフィールドの書式を「電子メール」から「テキスト」に変更します。

2. 次に「代理承認者」「代理承認開始日」「代理承認終了日」というフィールドをそれぞれ追加します。

代理承認者（検索 > ユーザー）：

代理承認開始日（日付）：

代理承認終了日（日付）：

3. 最後に「承認用メールアドレス」というフィールドを追加し、以下の計算式を設定していきます。

※最初に既定電子メールの書式を変更したのは、Dataverseの計算式機能が以下のような謎仕様になっているからです。（2024年2月現在）

必要なのはこれだけです。あとはPower Automateで承認機能を作成するときに、承認者を指定するところで「既定電子メール」ではなく「承認用メールアドレス」を使ってあげればそれでOKです。

以下は、①で承認ルートを取得⇒②で承認者のメールアドレスを取得⇒③で承認依頼をかけるというフローの例です。②の時に取得されるメールアドレスの値が、前述の計算式により必要に応じて代理承認者のものになっているというというのがポイントです。

今回の記事の本筋ではないですが、多段階の承認フローは上記のようにApply to eachでループを回すような実装方法がオススメです。

Microsoft Learnでは承認アクションを複数配置するような実装方法が紹介されておりますが、承認者が増えたり減ったりするたびにフローを修正することになり使いまわしができないので、個人的にはあまりおすすめできません。

「承認用メールアドレス」というフィールドは”計算式”という機能を使って作成します。

この計算式は簡単なIF文ですが、”今日という日が代理承認期間に含まれる場合は代理承認者のメールアドレスを、そうじゃない場合は本人のメールアドレスを返す”という意味です。

※DateAdd関数でUTC（協定世界時）を日本時間に補正しています。

例えば、Saitoさんが3月はずっとオーストラリアに遊びに行くからその間の承認は君に任せたよ、と私に言ってきた場合、以下のような設定をしておけばSaitoさんがオーストラリアにいる間だけ承認権限が自動的にSetoyaに委任される、ということになります。

PowerAppsとPower Automateを使って承認ワークフローの仕組みをつくる、という開発は当社でもこれまで散々やってきました。

Power Automateは非常にとっつきやすく最高に便利なツールではあるのですが、少し凝ったことをしようとすると一気に実装の難易度（というか、後から保守をする人の難易度）が上がってしまい、ノーコード開発の良さが失われてしまう、という側面があります。

今回の「代理承認機能の開発」というのもそのパターンの一つなのですが、このような場合、Power Automateでゴリゴリ頑張るのではなくて、ちょっと視野を上げてデザインを考え直してみると意外と簡単に実現することができたりします。

常にこのような発想ができるよう、日々精進していきたいものです。