合同会社小村ソフト
相談する
メニュー

Power Automateで承認フローを作る ── 紙とメールの稟議・申請を電子化する

· 更新日: · · Power Automate, 承認フロー, クラウドフロー, Microsoft 365, Teams, SharePoint, Forms, 業務自動化, 稟議, 技術相談

「稟議書を印刷して、押印して、隣の部署に回して、戻ってくるのが1週間後」「Excelの申請書をメールに添付して送り、承認は返信メールの『OKです』」。Microsoft 365を導入済みの会社から、こういう申請・承認業務を何とかしたいという相談をよく受けます。

Power Automateには承認(Approvals)という専用の仕組みがあり、TeamsやOutlookから承認ボタンを押すだけの承認フローを、追加費用なしのライセンス範囲で組めることが多いです。ただ、最初のフローが動くことと、業務として安心して回ることの間には距離があります。承認の記録はどこに残るのか、承認者が放置したらどうなるのか、担当者が退職したらフローは誰が直すのか。この記事では、承認フローの基本部品から、実務でつまずきやすい設計ポイント、そしてPower Automateでやるべき範囲の線引きまでを整理します。

1. まず結論

  • Power Automateの承認は 「開始して承認を待機」アクションが基本です。承認の種類は「全員の承認が必要」「最初の応答」「カスタム応答(全員/1人)」「順次承認」の5つから選べます。1
  • 承認者は Teams・Outlook・Power Automateポータル・モバイルアプリのどこからでも応答できます。承認のためだけに新しい画面の使い方を覚えてもらう必要はほぼありません。23
  • 申請の受け口は Microsoft Forms / SharePointリスト / Teamsの承認アプリの3択が現実的です。後から一覧・集計したいならSharePointリストを軸にするのが定石です。
  • フローの実行履歴は既定で28日しか見えず、1回の実行は最長30日でタイムアウトします。承認の証跡を実行履歴に頼らず、結果をSharePointリスト等へ書き戻す設計を最初から入れておきます。45
  • フロー所有者の退職・異動は承認フロー最大の運用リスクです。共同所有者の設定と接続の扱いを、動き始めた日のうちに済ませておきます。6
  • 条件分岐が多い多段承認、代理決裁や監査要件が厳しい稟議規程をそのまま実装しようとすると、Power Automateでは保守しきれなくなります。その場合はワークフローシステムや受託開発の領域です。

2. 紙・メール稟議の何が問題か

紙の稟議書やメール添付Excelの承認がつらいのは、手間そのものよりも「状態が見えない」ことです。相談を受けていて共通するのは、だいたい次の3つです。

  • 今どこで止まっているかわからない。稟議書が誰の机にあるのか、メールがどの受信トレイに埋もれているのか、申請した本人には見えません。催促は口頭か電話になり、催促される側も気分がよくありません。
  • 記録が散る。承認の証跡が、紙のキャビネットと個人のメールボックスに分散します。監査や後からの照会で「あの申請、誰がいつ承認したか」を調べるのに、人のメールボックスを漁ることになります。担当者が退職すればメールボックスごと消えます。
  • 差し戻しが追えない。却下や修正依頼が口頭・メールで行われると、どのバージョンの申請書に対する指摘だったのかが混ざります。修正版を再送すると、また最初から回覧です。

これらは「申請の状態と記録を1か所に集める」ことでほぼ解決します。そしてMicrosoft 365を導入済みなら、その置き場所(SharePoint)と通知経路(Teams/Outlook)と自動化(Power Automate)はすでに手元にあります。

3. Power Automate承認の基本部品

「開始して承認を待機」アクション

承認フローの中心は、承認(Approvals)コネクタの「開始して承認を待機(Start and wait for an approval)」アクションです。承認要求のタイトル・詳細・承認者を指定すると、フローはそこで停止し、承認者の応答を待ってから次のアクションへ進みます。1

承認の種類は5つあります。1

承認の種類 動き
承認/拒否 - 全員の承認が必要 全員が承認するか、誰か1人が拒否した時点で完了
承認/拒否 - 最初に応答 誰か1人が承認または拒否した時点で完了
カスタム応答 - すべての応答を待機 応答の選択肢を自分で定義。全員の応答で完了
カスタム応答 - 1つの応答を待機 応答の選択肢を自分で定義。1人の応答で完了
順次承認 指定した順番で1人ずつ承認を要求

カスタム応答を使うと、「承認」「却下」の2択ではなく「承認」「差し戻し」「保留」のような選択肢を定義できます。後述する差し戻しループの部品になります。

なお、承認機能を使うにはMicrosoft Dataverseのデータベースが必要です。承認要求や応答のレコードはDataverseに保存され、既定の環境では承認フローを最初に作ったときに自動的に用意されるため、通常は意識せずに使い始められます。承認コネクタは標準コネクタなので、標準コネクタを使えるライセンス(Office 365等)で承認フローを作成できます。1

承認者はどこから応答するか

承認者には、メールとPower Automateモバイルアプリで承認要求が届きます。3 Outlookでは整形された承認メールが届き、そこから応答できます。7 個人ユーザー宛ての承認はTeamsにも通知され、Teamsのチャットや承認アプリから承認・却下・コメント入力ができます。2 「承認のために専用サイトへログインしてもらう」というハードルがないことが、承認フロー定着の一番の推進力になります。

一点注意があります。承認先をMicrosoft 365グループにした場合、Teams通知は送られません。Teams通知が届くのは個人ユーザー宛ての承認だけです。8

フロー全体像

購買申請を例にすると、全体はこういう形になります。

Teams / Outlook / モバイル承認却下/差し戻しタイムアウトトリガー条件で「再申請」のみ起動申請者が入力Forms送信 / SharePointリストに登録クラウドフロー起動新しい応答・アイテム追加トリガー申請内容をSharePointリストへ記録状態: 承認待ち開始して承認を待機承認者へ要求送信応答リストの状態を「承認済み」に更新承認者・日時・コメントを列へ記録状態を「差し戻し」に更新申請者へ理由を通知督促通知 / エスカレーション申請者へ結果通知申請者が修正して再申請

ポイントは、承認アクションの前後に「記録」のステップを挟んでいることです。理由は5章で説明します。

4. 申請の受け口をどう設計するか

承認フローの使い勝手は、承認側よりも申請側の入力の受け口で決まります。現実的な選択肢は3つです。

観点 Microsoft Forms SharePointリスト Teamsの承認アプリ
入力のしやすさ フォーム形式で最も簡単。スマホからも入力しやすい リストの入力フォーム。列が多いとやや煩雑 Teamsのチャット・アプリから直接。フロー作成すら不要9
申請の一覧・状態管理 弱い(応答一覧はあるが状態列がない) 強い。列・ビュー・状態管理が本業 アプリ内の送信/受信一覧のみ
フローとの連携 トリガー「新しい応答が送信されるとき」+「応答の詳細を取得」の組で連携10 アイテム作成・更新トリガーで連携。承認チュートリアルの定番構成3 定型化はテンプレート機能で。フロー側の柔軟性は低い
添付ファイル ファイルアップロード質問で可 アイテムへの添付・ドキュメントライブラリ併用が自然 承認要求にファイル添付可
向くケース 申請項目が少なく、入力の手軽さ優先。既存Excel申請書の置き換え第一歩 申請台帳として残したい・件数が多い・後から集計したい 定型化するほどでもない都度の承認(そのつどの上長確認など)

判断の目安はこうです。

  • とにかく都度の承認だけ電子化したいなら、フローを作らなくてもTeamsの承認アプリで足ります。承認アプリはチャットからその場で承認要求を送れる機能で、Power Automateの基盤上で動きますが、フローの作成は不要です。9
  • 申請書の置き換えなら、Formsを受け口にして、応答をフローで受け取り承認に回すのが最短です。Formsの応答内容を承認要求に差し込むテンプレートも用意されています。11
  • 申請台帳として管理したいなら、SharePointリストを軸にします。Formsを入口にする場合でも、フローの最初で応答をリストに転記しておけば、状態列(承認待ち/承認済み/差し戻し)とビューで「今どこで止まっているか」が誰にでも見えるようになります。冒頭に挙げた紙・メール稟議の課題への答えは、実質ここにあります。

小規模に始めるなら「Formsで受けてSharePointリストに記録し、承認結果もリストに書き戻す」構成が、入力の手軽さと台帳管理の両取りができて扱いやすいです。

5. 実務で効く設計ポイント

承認記録をどこに残すか ── 実行履歴に頼らない

一番大事な設計判断です。フローの実行履歴は、既定では28日しか表示されません。4 ソリューションに含めたフローであれば実行履歴のメタデータをDataverseに残せますが、こちらも既定の保持は28日で、管理者が保持期間を調整する仕組みです。12

つまり「誰がいつ承認したか」を実行履歴で後から調べる運用は、1か月で破綻します。承認要求・応答のレコード自体はDataverseに保存されますが13、監査対応や日常の照会のたびにDataverseのテーブルを覗くのは現実的ではありませんし、承認履歴は環境の記憶域を消費するため、容量都合で削除の対象になることもあります。14

実務では、承認アクションの直後に、結果・承認者・応答日時・コメントをSharePointリストの列へ書き戻すステップを必ず入れます。「開始して承認を待機」アクションは応答・承認者・コメントを出力として返すので13、それをそのまま列に記録するだけです。申請と承認記録が同じリストの同じ行に揃い、保持期間はリストの運用次第で何年でも持てます。

1点だけ注意があります。「全員の承認が必要」やカスタム応答(全員)のような複数承認者の種類では、応答(Responses)は人数分の配列で返ってきます。3 これを1組の列に順に上書きで書き込むと最後の応答しか残らないため、複数承認者の記録は、応答ごとに履歴用リストへ1行ずつ追記するか、全員分の応答を1つのテキストに整形してから列へ記録する形にします。

タイムアウトとリマインダー ── 「期限のない承認」は作れない

クラウドフローの1回の実行は最長30日です。この30日には承認待ちのような保留中のステップも含まれ、30日を過ぎると保留中のステップはタイムアウトします。5 承認者が放置すれば、フローは黙って失敗で終わる。これを知らずに運用を始めると、「申請したのに何も起きない」という一番信頼を損なう事故が起きます。

対策は2段階です。

  1. 承認アクションに明示的なタイムアウトを設定する。アクションの設定でISO 8601形式(例: P3Dで3日)のタイムアウトを指定し、実行条件の構成で「タイムアウトした場合」の分岐を用意します。15 ここで注意したいのは、タイムアウトした時点で元の承認待ちは終了していることです。その後に承認者が応答しても、この実行の後続ステップ(結果の書き戻しなど)には流れません。つまりタイムアウト分岐は「待ち続けながら督促する」場所ではなく、「一度打ち切って次の手を打つ」場所です。督促するなら、タイムアウト分岐で通知を送った上で新しい承認要求を出し直します。「3日で督促、7日で上位者へ」程度の段数なら、タイムアウト付きの承認アクションを直列に2〜3段並べる(2段目は督促付きで再要求、3段目は上位者宛て)のが最も単純で確実です。「タイムアウト→督促→再要求」をDo untilループで巻く形も作れますが、Do untilにはループ自体の上限(既定で60回・1時間)が別にあり、承認待ちのような長時間のアクションを中に入れる場合は「制限の変更」でループのタイムアウトを明示的に延ばさないと、1周目のあと2周目以降が始まりません。516
  2. 30日を超える可能性がある承認は、フローを2本に分ける。「承認の作成(v2)」アクションで承認要求だけ送って1本目のフローは終了し、応答への後続処理は別フローで行う構成が公式に案内されています。承認レコードはDataverseにあるため、元のフローの実行が終わっても応答は処理できます。待機を打ち切らずに柔軟な督促を組みたい場合も、この2本構成のほうが素直に作れます。17 なお、2本目のフローの起動方法には設計の余地があり、承認テーブルの変更をDataverseコネクタのトリガーで直接拾う構成にする場合は、Dataverseコネクタがプレミアムライセンスの対象になる点に注意してください(承認コネクタ自体のアクションは標準の範囲です1)。18

中小企業の稟議であれば、まず「3日で督促、7日で上長へエスカレーション」のような社内ルールを決め、それを再要求ループまたは2本構成で実装するのが現実的です。

不在時の再割り当て

承認者が長期不在のケースは必ず起きます。承認要求を受け取った本人は、Power Automateポータルの承認一覧から要求を他の人へ再割り当て(Reassign)できます。一方、要求を出した側での立て直しは、要求のキャンセルと承認者の変更・再実行という手順になります。7 注意したいのは、この記事のような自動起動のフローでは、これは申請者ではなくフロー所有者側の作業になることです。承認要求はフローの接続に使ったアカウントから出ており、承認者の変更にはフローの編集権限が必要なためです。「承認者が休職したときは誰がフローを直すのか」を、次章の共同所有者の話とセットで決めておく必要があります。

ただし、再割り当ては「受け取った本人が操作できる」ことが前提なので、突発の休職などには効きません。恒常的な備えとしては、承認者を個人1名に固定せず、複数名をセミコロン区切りで指定して「最初に応答」型にするか、グループ宛てにする設計が安全です。7 グループ宛てはTeams通知が飛ばない制約8があるため、通知の確実性を重視するなら複数名指定を選びます。

却下時の差し戻しループ

紙の稟議で一番追いにくかった「差し戻し→修正→再申請」は、状態列を持つ設計なら素直に表現できます。基本形はこうです。

  • カスタム応答で「承認」「差し戻し」を定義する1
  • 差し戻しの場合、リストの状態列を「差し戻し」にし、承認者のコメントを列に記録して申請者へ通知する
  • 申請者はリストのアイテムを修正して状態を「再申請」に変える(またはFormsから再送信する)
  • アイテム更新をトリガーにフローが再度走り、承認へ回る

この形で1つ注意が要るのは、フロー自身の書き戻しでフローが再起動してしまうことです。「アイテムが作成または変更されたとき」トリガーのままだと、フローが状態列を「承認待ち」や「承認済み」に更新した瞬間、その更新自体がトリガー条件を満たし、二重の承認要求や無限ループが起きます。クラウドフローは自分自身をトリガーでき、Power Automateも保存時に無限ループの可能性を警告してきます。19 対策は、後段の条件分岐で捨てるのではなく、トリガー条件(trigger conditions)で「状態列が『再申請』(または新規作成)のときだけ起動する」とトリガー側に書くことです。トリガー条件を満たさない更新ではフローの実行自体が発生しないため、実行回数も消費しません。20

修正履歴はリストのバージョン履歴に残るため、「どの版に対する指摘か」が混ざる問題も解消します。フロー内でDo untilループを組んで1回の実行内で差し戻しを回す作りも可能ですが、30日の実行期間制限に差し戻しの往復時間も含まれてしまうため、差し戻しのたびに実行を終え、再申請で新しい実行を始める設計のほうが安全です。

6. 運用とガバナンス ── フローは「作った人のもの」にしない

承認フローは業務の基幹に入り込むため、属人化すると影響が大きくなります。最低限、次の2点は稼働初日に済ませます。

  • 共同所有者を設定する。フローの所有者は実行履歴の確認、フローの編集・停止、接続の資格情報の更新までできます。作成者1人のままだと、退職・異動した瞬間に誰も直せないフローになります。情報システム担当者や後任候補を共同所有者に追加しておきます。なお、SharePointリスト自体を共同所有者にして「リストの編集権限を持つ人=フローを編集できる人」に揃える機能もありますが6、この記事のように申請者全員が書き込む受け口のリストでこれをやると、申請者全員にフローの編集権限を渡すことになってしまいます。承認フローでは使わず、共同所有者は運用を担う担当者個人か管理者用のグループに限定してください。
  • 接続の扱いを理解しておく。フローで使う接続(SharePointやOutlookへの認証)は作成したユーザーに紐づき、共有された接続はそのフロー内でしか使えません。また共同所有者は他の所有者が作った接続の資格情報を変更できません。6 承認結果の通知メールが「退職した人のアカウント」から送られ続ける、アカウント無効化と同時にフローが止まる、といった事故はここから起きます。通知や書き込みに使うアカウントをどうするかは、フローを作る前に決めておくべき論点です。

なお、フローを他部署にも使ってもらう場合でも、申請する人たちにフローを共有する必要はありません。この記事の構成では、受け口(FormsやSharePointリスト)に入力できさえすればフローは自動で起動します。共有の対象は編集・運用に関わる人だけに絞り、共同所有者は必要最小限にとどめるのが原則です。21

ライセンス、環境分離、DLPポリシーといったPower Automate全体のガバナンスについては、別記事「Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計」で整理しています。承認フローもクラウドフローの一種なので、同じ考え方がそのまま適用されます。

7. どこまでPower Automateでやるか

Power Automateの承認は強力ですが、稟議規程をそのまま実装する道具ではありません。線引きの目安を挙げます。

状況 判断
承認者が1〜3段で、ルートが金額等のシンプルな条件で決まる Power Automateで十分
承認ルートが組織階層・金額・案件種別の組み合わせで動的に変わる 条件分岐が爆発しがち。ワークフローシステムまたは受託開発を検討
代理決裁・職務代行・組織改編への追従が要件にある Power Automate単体では作り込みが重い。専用システムの領域
監査要件で承認証跡の長期保存・改ざん防止・網羅的な検索が求められる SharePointへの書き戻しで足りるか要件次第。厳格ならワークフローシステム/文書管理システム
申請書のレイアウト再現(押印欄付き帳票の出力)が必須 フローの外で帳票生成の仕組みが必要。開発要素が入る

判断の感覚としては、「フローの分岐を紙に描いてA4に収まらなくなったら、Power Automateの守備範囲を超え始めている」くらいで見ています。無理にフローを育てるより、承認ルートの決定ロジックだけ外(Dataverseのテーブルや別システム)へ出す、あるいは専用システムへ移る判断のほうが、結果的に安く済むことが多いです。

また、承認フローの電子化は、社外との紙・FAXのやり取りを見直す入り口になることもよくあります。社内の稟議が電子化できたら、次はFAX受注や請求書のやり取りが候補です。このあたりは「FAX受注をWebに移すには ── 二重運用期間の設計と段階移行の実務」や「EDIとは？企業間の受発注をどう楽にするのか ── FAX・メール・手入力からデータ連携へ」で扱っています。

8. まとめ

紙とメールの稟議の本当の問題は、手間ではなく「状態が見えない・記録が散る・差し戻しが追えない」ことでした。Power Automateの承認フローは、この3つを「申請と承認記録をSharePointリストに集め、承認の操作はTeams/Outlookで済ませる」形で解決します。追加のシステム投資なしに始められることが多いのも、Microsoft 365導入済みの会社には大きな利点です。

一方で、実行履歴28日・実行期間30日という制約を知らずに作ると、「証跡が消える」「申請が黙って失敗する」承認フローができあがります。結果の書き戻し、タイムアウト分岐、複数承認者、共同所有者。この4点を最初から設計に入れておけば、承認フローは長く安心して回せます。そして、稟議規程の複雑さをそのまま実装したくなったときが、専用システムや受託開発を検討するタイミングです。

関連記事

関連する相談領域

合同会社小村ソフトでは、Microsoft 365を活かした業務フローの電子化の相談から、Power Automateでは収まらない承認・帳票要件のシステム化まで扱っています。

参考リンク

  1. Microsoft Learn, Get started with approvals. 「開始して承認を待機」アクション、承認の5種類(全員承認/最初の応答/カスタム応答/順次承認)、前提条件としてのDataverseデータベース、承認コネクタが標準コネクタでありOffice 365等のライセンスで作成できることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Respond to an approval from a chat or channel. Teamsのチャット・チャネル・承認アプリから承認要求に応答できることについて。 ↩ ↩2

  3. Microsoft Learn, Create an approval flow that requires everyone to approve. SharePointリストのアイテム作成・更新をトリガーにした承認フローの構成、承認要求がメールとPower Automateモバイルアプリで届くこと、全員承認では1人の拒否で全体が拒否になることについて。 ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Missing runs or triggers history for a flow. フローの実行履歴が既定で28日間しか保存されないことについて。 ↩ ↩2

  5. Microsoft Learn, Limits of automated, scheduled, and instant flows. クラウドフローの実行期間が最長30日であり、承認のような保留中のステップも30日経過でタイムアウトすることについて。 ↩ ↩2 ↩3

  6. Microsoft Learn, Share a cloud flow. 共同所有者ができること(実行履歴の確認、フローの編集、接続の資格情報更新、所有者の追加)、共有された接続がそのフロー内でしか使えないこと、他の所有者が作成した接続の資格情報は変更できないこと、SharePointリストを共同所有者にできることについて。 ↩ ↩2 ↩3

  7. Microsoft Learn, How to - Top scenarios with approval flows. 承認要求を受け取った本人による再割り当て(Reassign)、依頼側はキャンセルして承認者を変更すること、複数承認者のセミコロン区切り指定、Outlookでの承認メール表示について。 ↩ ↩2 ↩3

  8. Microsoft Learn, Request approvals from Microsoft 365 groups. グループ宛て承認の動き、Teams通知は個人ユーザー宛ての承認のみでグループ承認では送られないことについて。 ↩ ↩2

  9. Microsoft Learn, Approvals in Microsoft Teams. Teamsの承認アプリからフローを作らずに承認要求を作成できること、Power Automateの基盤で動作することについて。 ↩ ↩2

  10. Microsoft Learn, Overview of flows with Microsoft Forms. Formsのトリガー「新しい応答が送信されるとき」とアクション「応答の詳細を取得」について。 ↩

  11. Microsoft Learn, Common ways to use a form in a flow. Formsの応答内容を承認要求に差し込むテンプレート、応答のExcel/リストへの転記について。 ↩

  12. Microsoft Learn, Manage cloud flow run history in Dataverse. ソリューション対応フローの実行履歴(FlowRun)がDataverseに保存されること、既定の保持が28日で管理者が保持期間(TTL)を変更できることについて。 ↩

  13. Microsoft Learn, Differences between flow approval actions. 承認アクションがDataverseにレコードを作成すること、「開始して承認を待機」が応答・承認者・コメントを出力として返すこと、「承認の作成」と「承認を待機」の違いについて。 ↩ ↩2

  14. Microsoft Learn, Free up storage space. フローの承認履歴がDataverseの記憶域を消費し、削除により記憶域を解放できることについて。 ↩

  15. Microsoft Learn, Cloud flow error code reference. 承認・待機系アクションへの明示的なタイムアウト設定(ISO 8601形式)、「実行条件の構成」の「タイムアウトした場合」分岐、30日の実行期間制限への対処について。 ↩

  16. Microsoft Learn, Limits and configuration reference for Azure Logic Apps. Untilループの既定上限が反復60回・タイムアウト1時間(PT1H)であること、タイムアウトは周回ごとに評価され、超過すると実行中の周回は止まらないが次の周回が始まらないこと、「制限の変更」で値を変更できることについて。Power Automateのクラウドフローの反復既定値60回はLimits of automated, scheduled, and instant flowsにも記載。 ↩

  17. Microsoft Learn, Create and test an approval workflow with Power Automate. 30日を超える可能性がある承認では「承認の作成(v2)」を使い、承認要求の送信と応答の処理を2本のフローに分ける構成、承認要求のキャンセルについて。 ↩

  18. Microsoft Learn, List of all Premium tier connectors. Microsoft Dataverseコネクタがプレミアム層のコネクタに分類されていることについて。 ↩

  19. Microsoft Learn, Avoid anti-patterns. クラウドフローが自分自身をトリガーして無限ループになり得ること、保存時に警告が表示されること、トリガー条件やTerminateアクションによる回避策について。 ↩

  20. Microsoft Learn, Customize your triggers with conditions. トリガー条件により条件を満たさないイベントでは実行自体が発生しないこと、後段の条件分岐で捨てる方式では実行とAPI要求を消費してしまうことについて。 ↩

  21. Microsoft Learn, Understand flow ownership and access. 共同所有者は必要な場合に限り追加し、共有は原則として実行のみの権限で行うべきことについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

タスクスケジューラのタスクが実行されない・0x1で終わる ── 原因の切り分けと安全な運用設計

Windowsタスクスケジューラの実行アカウントとログオン種別、「ユーザーがログオンしているかどうかにかかわらず実行」の意味、0x1で終わる典型原因、履歴の有効化、多重起動防止、PowerShellスクリプトの正しい呼び出し方まで、定期実行を運用に乗せるための設計指針を整理...

記事を読む

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Power Automateの承認フローはMicrosoft 365のライセンスだけで作れますか？
作れます。承認(Approvals)コネクタは標準コネクタなので、標準コネクタを使えるライセンス(Office 365等)があれば承認フローを作成できます。ただし承認データの保存先としてMicrosoft Dataverseのデータベースが必要で、既定の環境では承認フローを最初に作成したときに自動的に用意されます。SharePointリストやForms、Teams、Outlookとの組み合わせも標準コネクタの範囲で構成できます。
承認者が応答しないまま放置されるとどうなりますか？
クラウドフローの1回の実行は最長30日で、承認待ちのような保留中のステップも30日を過ぎるとタイムアウトします。そのため「期限を設けない承認」は作れません。実務では承認アクションに明示的なタイムアウトを設定し、『実行条件の構成』で「タイムアウトした場合」の分岐を用意します。タイムアウトすると元の承認待ちは終了し、その後の応答は後続ステップに流れないため、この分岐では督促通知とあわせて新しい承認要求を出し直す(繰り返し回数に応じて上位者へエスカレーションする)設計にします。30日を超えて待つ必要があるなら、承認の作成(v2)アクションと応答を処理する別フローの2本構成に分けます。
承認の記録はどこに残りますか？監査に使えますか？
承認要求や応答はMicrosoft Dataverseにレコードとして保存され、フロー自体の実行履歴は既定で28日しか表示されません。監査や後からの照会を実行履歴に頼るのは危険です。実務では、承認結果・承認者・承認日時・コメントをフローの最後でSharePointリストの列に書き戻し、申請データと承認記録を1か所で一覧できるようにしておく設計をお勧めします。
承認者が不在・退職のときはどうすればよいですか？
承認要求を受け取った本人は、Power Automateの承認一覧から他の人へ再割り当て(Reassign)できます。依頼した側は再割り当てできませんが、要求をキャンセルしてフローの承認者を変更して再実行できます。恒常的な不在に備えるなら、承認者を個人1名に固定せず複数名やグループへ送る設計にしておくと詰まりにくくなります。フロー自体の所有者の退職に備えて、共同所有者を最初から設定しておくことも重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る