Power automateで汎用承認フローを作ってみる - 業務の隙間を埋める技術メモ。

Power Automateで汎用承認フローを作ってみようと思います。

Power Automateは、手軽に承認フローを作れるのが売りのひとつです。ただし「フローを作るツール」であるがゆえに、普通に作ると柔軟性に欠けがちです。

たとえば、

承認者が部署ごとに異なる
金額によって承認階層が変わる
運用開始後に承認ルールが頻繁に変わる

といったケースでは、その都度フロー自体を修正する必要が出てきます。

そこで今回は、承認階層や承認先をパラメータ化し、フローを作り直さなくても様々な承認形態に対応できる「汎用承認フロー」を作ってみました。

あくまで「やってみた」記録ですが、同じような悩みを持っている人のヒントになればと思います。

全体設計の考え方

今回のポイントはとてもシンプルで、

承認フローを Power Automate で定義しない

という割り切りです。

Power Automateはあくまで実行エンジンとし、
「誰が・どの順番で・どんな条件で承認するか」はすべてデータで定義します。

そのために、以下の4つのテーブルを用意しました。

フロー定義マスタ
タスク定義マスタ
申請トランザクション
承認履歴

このうち、特に重要なのが「フロー定義マスタ」と「タスク定義マスタ」です。

テーブル設計

フロー定義マスタ

「どんな承認フローが存在するか」を定義するテーブルです。

項目名	内容
フローID	承認フローを識別するID
フロー名	稟議、経費精算など
有効フラグ	使用中かどうか

ここでは、承認者や条件は一切持たせません。
あくまで「フローの箱」だけを定義します。

タスク定義マスタ（汎用化の肝）

承認の流れをすべて定義するテーブルです。

項目名	内容
フローID	対象となるフロー
承認順	1次承認、2次承認…
承認者種別	直属上司／部署長／個人指定
承認者ID	ユーザーIDまたは部署ID
金額下限	この金額以上で有効
金額上限	この金額未満で有効

ここで、

承認の順番
誰が承認するか
どの条件で有効になるか

をすべてデータとして表現します。

これにより、

5万円以上は部長承認
10万円以上は役員承認
部署ごとに承認者が違う

といった要件も、フローを修正せずにマスタ変更だけで対応できます。

申請トランザクション

ユーザーが実際に申請するデータです。

項目名	内容
申請ID	トランザクションID
フローID	使用する承認フロー
申請者	申請ユーザー
金額	承認条件判定用
ステータス	申請中／承認中／完了

Power Appsなどから、このテーブルにレコードが作成される想定です。

承認履歴

承認のログを残すためのテーブルです。

項目名	内容
申請ID	対象申請
承認順	何次承認か
承認者	実際の承認者
結果	承認／却下
実行日時	承認日時

あとから「なぜこの申請が通ったのか」を説明できるようにするため、
業務利用では必須だと感じました。

Power Automate 側の実装

フローは1本だけ作ります。

トリガー

申請トランザクションが作成されたとき

処理の流れ（概要）

申請トランザクションからフローIDと金額を取得
タスク定義マスタを検索
- フローIDが一致
- 金額条件に合致
承認順で並び替え
Apply to each で承認処理を順番に実行
承認結果を承認履歴に保存
最終承認後、申請ステータスを「完了」に更新

承認自体は、標準の
「承認の開始と待機」アクションをそのまま使っています。

実際に使ってみての所感

良かった点

フロー修正がほぼ不要
承認条件の変更がマスタ修正だけで済む
運用開始後の変更に強い

特に「とりあえず回しながら調整したい」業務では、
かなり扱いやすい構成だと感じました。

ハマった点・反省点

Apply to each のネストが深くなると可読性が下がる
承認待ちが長いとフローの実行時間が延びる
エラー時のリカバリ設計は必須

途中状態をテーブルに保存し、
「どこで止まっているか」が分かるようにしておくのが重要でした。

まとめ

Power Automateは手軽ですが、そのまま作ると
「あとから変えにくいフロー」になりがちです。

今回のように、

承認ロジックはデータで管理
フローは解釈と実行に専念

という構成にすると、
ローコードでも業務に耐える仕組みを作れると感じました。

汎用化というほど大げさではありませんが、
現場で困らないための一工夫としては、やってみる価値はあると思います。