はじめに
Xで投稿したこちらの内容に反響があったので、簡単にまとめておきます。
SharePoint リストで承認の構成をしたときに行える承認依頼を、Power Automate で開始する方法です。
承認の構成とは
前提となるので説明しておきます。ご存じの方は飛ばしてください。
構成を開始する
SharePoint リストで、自動化>承認の構成を行って使うことができる機能です。
使用するには、初めに構成を行う必要があります。
有効化すると、承認を開始するためのボタンの表示された列が追加されます。
構成される列
| 列 | 内容 |
|---|---|
| 承認作成者 | 承認を開始(要求)したユーザー |
| 承認者 | 承認者として設定されたユーザー(複数ユーザー列) |
| 返信 | 承認に応答したユーザー(複数ユーザー列) |
| 承認の状態 | 承認を開始するボタン。内部的には数値となっている。(後述します) |
承認を要求する
ボタンを押して承認のタイトルや承認者・承認の種類、詳細メッセージを入力して送信します。
リストアイテムの編集権限がないユーザーは、承認を要求することができません。
※ 閲覧・投稿のみの権限では不可
承認通知
承認通知は通常の承認と同じように承認アプリから届き、TeamsやOutlookなどで確認できます。
通常の承認との違いに、SharePointのロゴがついていることや、承認元となったリストアイテムへのリンクが添付ファイルとしてついていることがあります。
承認通知自体は確認できますが、リンクはそのリスト（アイテム）への閲覧権限がないと表示できません。
承認の完了
完了すると、リスト側に結果が自動的に反映されます。
承認の状態や結果はリストから確認できます。
開始時と同じように、ボタンをクリックすると表示され、ここから承認を進めることもできます。
内部的な値
表示上ではボタンになっていますが、内部の値を取得すると数値で取得できます。
| 承認の状態 | 実際の値 |
|---|---|
| 未送信 | 0 |
| 要求済み | 1 |
| 拒否済み | 2 |
| 承認済み | 3 |
承認後のアイテムの編集
承認の要求後にアイテムを編集すると、承認の状態がリセットされます。
承認した後でこっそり書き換えようとしてもできないというわけですね。
承認の自動化
という感じで、承認の状態とリストアイテムが密接に連携しており、使い勝手の良い機能です。
ただし、要求は手動で開始する必要があり、「アイテムの作成と同時に承認を開始したい」「決まった承認ルート以外での承認を設定されては困る」 など、自動化への要求もあるかと想像します。
この記事ではPower Automate を使用して承認の要求を行う方法を説明します。（ようやく本題）
類似の機能
同じく自動化のメニュー、クイック操作から承認を開始することもできます。
しかしながら、こちらの機能も手動でクイック操作を開始する必要があること。また、特定の役職者など承認ルートを柔軟に設定できない点で同様の問題があります。
Power Automateで承認を開始する
アイテムが作成されたときをトリガーに、自動的に承認を開始するフローを作成してみました。
2025/07/02追記
専用のアクションが追加になっていましたので、後述のHTTPリクエストは不要になりました。
SharePoint のHTTPリクエストを使用しており、プレミアムコネクタなしで実行可能です。
POST
_api/SP.Approvals.CreateItemRequest
{
"creationInfo": {
"listId": "リストを特定するためのID",
"itemId": "リストアイテムのID",
"url": "",
"version": "",
"approvers": "セミコロン区切りのuserPrincipalName",
"title": "承認のタイトル",
"details": "承認の詳細メッセージ",
"awaitAll": true,
"itemUrlType": 0,
"markDocAsFinal": false
}
}
ドキュメントが見つけられず、一部不明確なプロパティもあるのですが、わかっている範囲でボディの中身を解説します。
listId
listIdはリストを特定するための内部的なIDです。
リストの設定画面のURLなどから確認可能です。
私は、トリガーで同じ値を指定しているので、参照して使用しています。
trigger()?['inputs/parameters/table']
itemId
itemIdは承認を行うリストアイテムのIDです。
トリガーから動的なコンテンツを使用しています。
approvers
approversは、承認者を設定するための項目です。
複数人設定する場合は、セミコロン;区切りのuserprincipalNameで設定します。
申請者の上司など、ワークフローに従って設定してください。
title / details
titleは承認のタイトルです。リストアイテムのタイトルと一致させる必要はありません。
detailsは承認のメッセージですね。書式設定が必要な場合は、Markdownを使用します。こちらもリストアイテムと合わせる必要はありませんが、もしリストアイテムへの閲覧権限がない場合は、しっかり詳細を記載してあげる必要があるかと思います。
awaitAll
awaitAllは承認の種類を表すプロパティです。
そもそもこのキーがない場合は「連続した承認」、trueにすると「連続した承認ではなく、かつすべての承認者からの回答が必要」、falseにすると「連続した承認ではなく、かつすべての承認者からの回答は必要ない」ということになります。
Power Automateで承認結果を確認する
このリクエストの実行は、あくまでも承認を開始するのみとなり、このアクションでは承認結果を取得することができません。
ただし、承認の状態はDataverseのApprovalテーブル等に保存されるため、SharePoint以外の通常の承認と同様に扱うことができます。
承認を待機アクションを使用することで、結果を待機して取得することが可能です。
body('SharePoint_に_HTTP_要求を送信します')?['d/CreateItemRequest']
注意点
承認を要求するユーザーは、フローでのアクションの実行した接続に依存するようです。
リストアイテムの作成者にはできないようなので、フローの実行者を工夫する・承認ルートにアイテムの作成者を含めるなどで対応する必要があるかと思います。
どうしても要求元を申請者本人にしたい場合は、インスタントトリガーを使用して、「実行専用のユーザー」の接続を使用することでも可能かと思います。
ただし、アイテムの作成と同時に…とはいかなくなるので、
-
クイックステップからフローを実行させる - リストの書式設定でフローの起動ボタンを用意する
- Power Apps からアイテムの作成と同時に起動させる
などのトリガーの工夫が必要です。
おわりに
個人的には先に説明のトリガーの問題で、自分のやりたいことにはマッチしなかったのですが、要望があったので記事にまとめておきました。
承認の構成自体はとてもいい機能だと思うので、バランスを意識してうまく使ってもらえると幸いです。