【Power Apps & Power Automate】初心者でも実践可能!Dataverse for Teamsで始める承認フロー構築ガイド

日々の業務において、稟議書、経費精算、休暇申請など、様々な「承認」プロセスが存在します。これらの多くが依然として紙媒体や口頭で行われており、プロセスの停滞や進捗の不透明性、情報共有の阻害を引き起こす一因となります。

本記事では、Microsoft Power Platformの中核をなす Power AppsPower Automate、そして Dataverse for Teams を活用し、これらの承認業務を効率化する「承認フロー」アプリケーションの基礎的な構築手順を、初心者の方にも分かりやすく丁寧に解説します。

この記事を最後までお読みいただくことで、コーディングの専門知識がなくとも、ご自身の業務に即した実践的な承認アプリを構築するための知識とスキルを習得できます。

なお、本記事では承認者の一人が応答すれば完了する最も基本的なパターンを「基礎編」として扱います。これを土台とし、続編の「応用編」では、複数人が順番に承認する連続承認(承認チェーン)や、関係者全員の承認を必須とするといった、より実践的なフローの構築方法も解説していく予定です。まずはこの記事で、承認フロー自動化の第一歩を確実に踏み出しましょう。

Power Platformも学べる!オンライン学習ならUdemy

Udemy(ユーデミー)は、仕事に役立つスキルから趣味のトピックまで、「学びたい」が見つかるオンライン学習プラットフォームです。Power AppsPower Automate をはじめとする Power Platform 関連講座も充実しており、業務効率化スキルをしっかり学べます。

今すぐUdemy講座をチェックする

データ基盤の選定:なぜDataverse for Teamsなのか?

承認フローを構築する上で、申請データを格納するデータベースは不可欠です。Power Appsで利用するデータベースにはSharePointリストやExcelを利用するケースも多く見られますが、ここではDataverse for Teamsの利用を想定して紹介します。

Dataverse for Teamsは、Microsoft Teamsライセンスの範囲内で追加費用なく利用できる、非常に強力なデータベース機能です。その主なメリットは以下の通りです。

  • 高度なセキュリティ
    テーブルごと、さらには行レベルでの厳密なアクセス許可設定が可能であり、内部統制の観点からもセキュアなデータ管理を実現します。
  • 優れた拡張性と一貫性
    Power Platformの各サービス(Power Apps, Power Automate, Power BI)と極めて親和性が高く、申請アプリから承認の自動化、データの可視化・分析までをシームレスに連携できます。
  • 容易な環境構築
    Microsoft Teams上で数クリックするだけで、アプリケーション開発環境とデータベースを同時に準備できます。

このように多くの利点を持つ一方で、利用にあたっては以下の点に留意する必要があります。

  • 容量制限
    Dataverse for Teamsの環境は、1環境あたり2GBという容量上限が設定されています。大量の添付ファイルや画像データを扱う可能性がある場合は、将来的にDataverseのフルライセンスへのアップグレードを視野に入れるか、添付ファイルのみをSharePointドキュメントライブラリに保存するといった設計上の工夫が求められます。
  • 環境の範囲
    作成されたアプリやフローは、そのTeamsチーム内での利用が基本となります。組織全体で利用するような大規模なアプリケーションには、通常のDataverse環境が適しています。

これらの特性を理解した上で、部門内やチーム単位での業務改善からスモールスタートするには、Dataverse for Teamsは最適な選択肢と言えるでしょう。今回は、このDataverse for Teamsを基盤として、物品購入の申請と承認を行うサンプルアプリを構築していきます。

今回作成するサンプルアプリの概要

構築手順に入る前に、今回作成する「物品購入申請アプリ」が、完成後にどのように動作するのか、その全体像を見ていきます。このアプリは「申請者」と「承認者」の2つの視点で利用されます。

申請者の操作フロー

申請者は、Power Appsで作成されたアプリを使い、物品購入の申請を行います。

  • 申請内容の入力と提出
    まず、申請者はアプリを起動し、購入したい物品の名称、金額、理由などをフォームに入力して申請ボタンをクリックします。

  • 申請状況の確認
    申請が提出されると、申請一覧画面でステータスが「申請中」として表示されます。これにより、申請者は自身の申請がどの段階にあるかを確認できます。

承認者の操作フロー

申請が提出されると、Power Automateによって承認プロセスが自動的に開始され、承認者に依頼が届きます。

  • 承認依頼の受信
    承認者は、Microsoft Teamsのアクティビティ通知やOutlookのメールで、承認依頼を受け取ります。依頼には申請内容の詳細が含まれており、この通知上で直接アクションを起こせます。

  • 申請の承認または却下
    内容を確認後、「承認」または「却下」ボタンをクリックします。必要に応じてコメントを追記することも可能です。承認者がこの操作を完了すると、その結果が即座にシステムに記録されます。なお、承認者は申請一覧画面上で、直接承認または却下操作を行えるようにも設計しています。

プロセス完了後の動き

承認者のアクションに応じて、システムは自動的に後続処理を実行します。

  • 結果の自動通知とデータ更新
    承認結果は、Power Automateを通じて申請者に自動で通知されます。同時に、Dataverse for Teamsのテーブルデータも更新され、Power Apps上のステータス表示が「承認済み」または「却下」に変わります。承認者や承認日の情報も自動的に記録されます。

このように、申請から承認、結果の記録と通知までの一連のプロセスを自動化するアプリケーションを、次のセクションから実際に構築していきます。

準備編:Dataverse for Teamsにテーブルを作成する

まず、申請データを格納するためのデータベースのテーブルを準備します。

表示名データ型役割
申請番号テキスト各申請を一意に識別するための管理番号(プライマリ列)
申請件名テキスト申請の内容を簡潔に記載する
申請者テキスト申請者の名前
申請日日付のみ申請が行われた日付
品名テキスト購入したい物品の名前
金額数値物品の金額
理由テキスト(複数行)購入理由を詳細に記述する
承認ステータス選択肢「申請中」「承認」「却下」の選択肢を設定
承認者テキスト承認または却下を行った人物の名前
承認日日付のみ承認または却下が行われた日付

特に「承認ステータス」は、フローの進捗を管理する上で極めて重要な列となります。

構築編①:Power Appsで物品購入申請アプリ画面の構築

次に、Power Appsでアプリのインターフェースを構築していきます。今回は、複数のスクリーンを用意するのではなく、1つのスクリーン上で役割の異なるパーツを切り替えて表示する方法を採用しました。

具体的には、1つのメインスクリーン上に、以下の2つの主要なパーツを配置します。

申請一覧: 提出された申請のステータスを確認するための一覧です。この一覧は、申請者にとっては「自身の申請履歴」、承認者にとっては「承認すべき案件一覧」として機能します。
新規申請: 申請者が購入したい物品の情報を入力するためのフォームです。

実装方法としては、これらのパーツをそれぞれ別の「コンテナ」コントロールでグループ化し、画面に配置します。そして、ユーザーがタブやボタンをクリックする操作に応じて、表示するコンテナを切り替える(Visibleプロパティを制御する)仕組みを構築します。

個々の画面の細かな作り込みは、この記事の本筋ではないため、ここでは各パーツがどのような仕組みで動作するのか、その要点に絞って簡潔に解説します。

申請一覧の実装

一覧表示には、ギャラリーコントロールを利用します。このギャラリーは、アプリのモード(申請者モード/承認者モード)に応じて、表示するデータを自動で切り替えるように設定します。

  • 申請者モードでは、自分が過去に申請したデータのみが表示されます。
  • 承認者モードでは、自分に承認が割り当てられており、かつ「申請中」の案件のみが表示され、一覧から直接「承認」や「却下」のアクションを行えるボタンも表示されます。

このように、1つのギャラリーでも数式を工夫することで、見る人の役割に応じた最適な表示を実現できます。

新規申請フォームの実装

申請情報の入力には、フォームコントロールを利用します。フォームのデータソースを「物品購入申請」テーブルに接続し、DefaultMode プロパティを FormMode.New に設定して、常に新規入力状態で開くようにします。
ここ画面で最も重要なのが「申請を送信」ボタンの挙動です。このボタンの OnSelect プロパティに、データの保存から承認フローの開始までの一連の処理を記述していきます。

ボタンがクリックされると、以下の処理が順番に実行されます。

  1. 申請番号の自動採番: 最初に、重複しない申請番号を生成するためのPower Automateフローを呼び出します。
  2. データの保存: 次に、フォームに入力された内容と①の申請番号を、Dataverseのテーブルに新しいレコードとして保存します。
  3. 承認フローの開始: 最後に、②で保存したレコードのIDを、メインの承認フロー(Power Automate)に引き渡して、承認プロセスを開始させます。
  4. 画面の更新: 処理が完了したことをユーザーに通知し、表示画面を申請一覧へ自動で切り替えます。

この一連の流れを実際に記述したOnSelectプロパティのコードが以下です。一見すると長く見えますが、上記の4つのステップが順番に記述されていることが分かります。

このように、Power Appsはユーザーとの窓口として機能し、実際の複雑な処理はPower Automateと連携して実行するのが、効率的なアプリを構築する上でのポイントとなります。

構築編②:Power Automateで承認フローを自動化する

ここからが本システムの核となる、Power Automateによる承認フローの作成です。Power Appsで申請データが保存された直後にこのフローが呼び出され、承認プロセスが自動的に開始されます。

1. トリガー: Power Apps (V2)

まず、フローの起点となるトリガーを設定します。
このトリガーの役割は非常にシンプルで、Power Appsから渡された「レコードID」を受け取ることだけです。Power Apps側で申請データが作成された後、そのデータのユニークなIDがこのフローに引き渡されます。

2. アクション: ID で行を取得する

次に、受け取ったIDを使って、承認に必要な情報をDataverseから取得します。
このステップは、フローの正確性を担保する上で非常に重要です。トリガーで受け取ったIDを使い、申請されたレコードの全データ(申請者名、品名、金額、理由など)をデータベースから直接取得します。これにより、常に最新の正しい情報に基づいて承認プロセスを進めることができます。

3. アクション: Start and wait for an approval (承認を開始して待機)

取得したデータを使って、承認者に承認依頼を送信します。
このフローの中心的なアクションです。前のステップ「ID で行を取得する」で得られた動的なコンテンツ(申請者名や品名など)を「タイトル」や「詳細」に設定し、承認者が一目で内容を把握できる承認依頼カードをTeamsやOutlookに送信します。

4. アクション: Condition (条件)

承認者の応答に応じて、その後の処理を分けます。
承認者が「Approve(承認)」ボタンを押したか、それ以外(却下)かをOutcomeの値で判定し、処理を「はいの場合」「いいえの場合」に分岐させます。

5. アクション: Update a row (行を更新する)

最後に、承認結果をDataverseのレコードに記録します。
「はい」「いいえ」それぞれの分岐の中にこのアクションを配置します。

  • 行 ID: トリガーで受け取ったIDを再度ここで指定し、更新対象のレコードを正確に特定します。
  • 承認ステータス: 「はい」の分岐ではステータスを「承認」に、「いいえ」の分岐では「却下」に更新します。
  • 承認日: formatDateTime(utcNow(), ...) などの式を使い、承認者がアクションを実行した日時を記録します。

以上のステップで、申請から承認、結果の記録までが完全に自動化されました。このフローをPower Appsの申請ボタンに連携させることで、シームレスな承認システムが完成します。

まとめ

本記事では、Power Apps、Power Automate、そしてDataverse for Teamsを連携させ、実践的な承認フローを構築する手順を解説しました。

  • Dataverse for Teamsでセキュアなデータ基盤を構築
  • Power Appsで直感的な申請インターフェースを作成
  • Power Automateで承認プロセスを完全に自動化

この仕組みを導入することで、ペーパーレス化の推進、承認プロセスの迅速化と可視化を実現し、組織全体の生産性を飛躍的に向上させることが可能です。

今回ご紹介したのは、担当者のうち誰か1人が応答すれば完了する、最も基礎的な承認フローです。しかし、実際の業務ではより複雑な承認ルートが求められることが一般的です。

本記事の内容を基礎編とし、今後の応用編では、以下のような発展的なテーマを取り上げる予定です。

  • 複数の承認者による連続承認(部長→本部長など、承認チェーンの構築)
  • 担当者全員の承認をもって完了とする(全員一致での承認)
  • 申請内容に応じて承認者を動的に変更する方法

ぜひ、本記事を参考に、まずは身近な業務のDXへの第一歩を踏み出してください。

Power Platformも学べる!オンライン学習ならUdemy

Udemy(ユーデミー)は、仕事に役立つスキルから趣味のトピックまで、「学びたい」が見つかるオンライン学習プラットフォームです。Power AppsPower Automate をはじめとする Power Platform 関連講座も充実しており、業務効率化スキルをしっかり学べます。

今すぐUdemy講座をチェックする