アプリ開発の調査にかかる
時間を削減したい
内製化支援サービス
アプリを自分たちで
作成できるようになりたい
DX人材育成プログラム
プロに開発を依頼したい
アプリ開発導入支援サービス
SharePoint デザイン拡張サービス
X-SP Design
モダン化から運用管理までサポート
SharePoint 構築支援サービス
SharePointで社内ポータルサイトを構築する際、「申請・承認プロセスを自動化したい」といったご相談をよくいただきます。
Power AutomateはMicrosoft 365に含まれるローコード自動化ツールで、SharePointと連携してさまざまな業務フローを自動化できます。
本記事は、Power Automateの基本操作（例：フローの新規作成やトリガー・アクション追加）ができる方を想定していますが、
「Power Automateは使ったことがあるけど、SharePointとの連携や承認フローは初めて」という方にも分かりやすいよう、段階的に手順やポイントを解説します。
デフォルトのPower Automate承認フローをそのまま使うこともできますが、実運用では「保守性」「柔軟な運用」「エラー対応」などの観点から、自社に最適な承認フローを設計・構築することが大切です。
特に、実運用に耐える承認フローを作るには、要件に合わせたカスタマイズや将来的な保守性を意識した設計が不可欠です。
しかし、いざカスタマイズしようとすると
「どこから手をつけて良いかわからない」
「エラーの原因特定や対処法がわからない」
「意外と設定が複雑」
といった課題に直面することも少なくありません。
また、承認フローの大まかな部分については簡単に作成できますが、本当に重要なのは「実運用に耐えうる処理とする」ことや「保守性の高い」フローを構築することです。
そこで今回は、SharePointの承認フロー構築において重要な設計の考え方と、実運用を見据えた具体的な実装方法を、実際のフロー構築例とともに詳しく解説します。
また、関連する実践的なブログ記事もご紹介しますので、実運用・保守性を意識した承認フローの作り方を知りたい方はぜひ参考にしてください。
【このシリーズの過去回一覧】
もし記事を読んで
「自社でも承認フローを導入したい」「もっと効率的な運用方法を知りたい」と感じた方や、
具体的な設計・構築でお困りの方は、アーティサン株式会社の各種サービスもご活用いただけます。
現場の課題やご要望に合わせて、SharePointやPower Platformの導入・運用をサポートしていますので、ぜひお気軽にご相談ください。
前回は、承認フローについて、トリガー → 準備 → 承認前の処理まで作成いたしました。
今回は、承認の処理以降を作成し、フローを完成させます！
今回の要件
改めて、今回の要件ついて説明します。
要件
SharePointサイト内で作成した各種リソースについて申請・承認機能（承認フロー）を実装する
対象は以下
サイトのページ（ニュース・ページ）
リスト内のアイテム
ドキュメントライブラリ内のドキュメント
承認者は固定
必要に応じて、申請者や承認者、サイトの閲覧者に通知する
実運用・保守性を考慮した設計とする
構築した承認フロー
全体像イメージ
※注意※
以下のフローは、ドキュメントライブラリ用に作成しています。
サイトのページ（ニュース・ページ）やリストアイテムの場合適宜読み替える箇所がありますが、詳細についてはフローを説明する中で紹介します。
承認フローの構造
承認フローの構造としては、全部で6ステップに分割することができます。
各ステップでの内容は以下の通りです。
トリガー
フローを起動する際のトリガーです。
準備
値を取得するアクションや変数の定義を行います。
「値を取得するアクション」の必要性については、以下ブログに記載しておりますので、ご参照ください。承認前の処理
承認依頼を出す前に行う処理です。
今回は、申請されたレコードに対して、プロパティ（申請者・申請日時）を追加する処理を行っています。
また、今回は実装していませんが、承認者をマスタから検索するという処理も、こちらに入れる場合があります。承認の処理
承認の処理です。
承認者に対して、承認依頼を通知します。承認後の処理
承認された後の処理です。
今回は、指定された公開日時まで待機する処理や、
申請されたレコードに対して、プロパティ（公開日時）を追加する処理を行っています。
また、公開された際には申請者やサイト閲覧者に対して通知する処理も実装しています。フローにエラーが発生した場合の処理
フロー全体でエラーが発生した場合の処理です。
考え方などについては、以前ブログを作成しておりますので、こちらもご確認ください。
前回は、ステップ3：承認前の処理まで構築しました。
今回は、ステップ4：承認の処理から説明していきます。
Step4：承認の処理
本ステップでは、実際に承認依頼を出していきます。
具体的な処理は以下となります。
変更チェック
Point：Etagを用いた変更チェック
実際の運用が始まると、申請したけど内容が間違っていたので修正したいという要望があるかと思います。
ただし、Power Automateは一度フローが実行されてしまうと、Power Automateの画面でフローをキャンセルしない限り動作し続けてしまいます。
よって本フローでは、Etagを用いることにより、フローが実行された後にファイルやニュースが編集されていないかを確認します。
参考：Etagとは？
大まかにいうと、リソースが編集された際に加算されていく値です。
今回は、申請時のEtagと承認を出す直前のEtagを比較することにより、申請されてから承認依頼を出す前までに、編集されていないかを確認します。
まずは「ファイルのプロパティの取得」アクションでEtagを取得します。
設定値は以下です。
アクション名 | プロパティ | 値 | 備考 |
|---|---|---|---|
ファイルのプロパティの取得：承認処理 | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/ID’] |
「条件」アクションでは、申請時のEtagと承認を出す直前のEtagを比較しています。
設定値は以下です。
アクション名 | 左辺 | 式 | 右辺 |
|---|---|---|---|
条件：承認前に編集されている場合は終了 | int(replace(string(outputs(‘ファイルのプロパティの取得：申請’)?[‘body/@odata.etag’]), ‘”‘, ”)) | 次の値に等しい | add(int(replace(string(outputs(‘ファイルのプロパティの取得：承認処理’)[‘body/@odata.etag’]), ‘”‘, ”)), -2) |
式が長くて分かりづらいですが、処理内容としては以下です。
Etagを取得
ダブルクオーテーションを削除
数値に変換
（右辺のみ）値を-2
右辺（承認直前のEtagの値）を-2している理由ですが、承認フローの中でプロパティの更新と「承認の状態」列を変更しているからです。
上記の処理を行った際に、それぞれEtagが+1されます。
Etagチェックがエラーになった場合は、申請者へ通知を行い、フローを終了しています。
※今回通知の処理については割愛しております。TeamsやOutlookを用いて通知しましょう。
承認依頼の通知
Etagチェックが無事に終了した場合は、承認依頼を通知しましょう。
詳細は上記をご確認いただければわかるかと思います。
却下された場合には、「承認の状況」列を却下になるように設定しましょう。
「コンテンツの承認状態を設定します：Rejected」アクションの設定は以下のとおりです。
アクション名 | プロパティ | 値 | 備考 |
|---|---|---|---|
コンテンツの承認状態を設定します：Rejected | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/ID’] | |
Etag | outputs(‘コンテンツの承認状態を設定します：Submit-承認前処理’)?[‘body/ETag’] |
もし「自社の要件に合わせた承認フローの設計や、Power Automateの活用方法についてもっと詳しく知りたい」 「専門家に相談したい」といったご希望があれば、アーティサン株式会社のサービスもご検討ください。
現場の課題やご要望に合わせて、最適なご提案・サポートを行っています。
Step5：承認後の処理
続いて、承認後の処理です。
本ステップでは、承認がOKとなった場合に行う処理を記載します。
本ステップでの具体的な処理は以下となります。
公開の開始日まで待機
まずは公開の開始日まで待機します。
Point：公開の開始日の空白チェック
「遅延期限」アクションのタイムスタンプ プロパティは、値が空白の場合、エラーとなってしまいます。
上記エラーを防ぐため、公開の開始日が空白でない場合にのみ、待機するようにしています。
「条件」アクションの設定は以下のとおりです。
アクション名 | 左辺 | 式 | 右辺 |
|---|---|---|---|
条件：公開日時まで待機 | empty(outputs(‘ファイルのプロパティの取得：申請’)?[‘body/PublishStartDateTime’]) | 次の値に等しい | true |
Etagのチェック
続いてEtagのチェックを行います。
Step4：承認の処理と同一ですので、詳細は割愛します。
公開日時の更新
承認後に、公開日時を更新してします。
Point：「公開日時」列には、公開する直前の値（=utcNow()）を設定している理由
承認されたデータを社内ポータルに表示させる際、「新しく公開された情報を上部に表示したい」という要望を多く伺います。
一方で、「承認されたらすぐに公開したいので、特定のデータについては申請時に公開日を設定したくない」という要望もあります。
また運用を開始すると、「公開日を設定したが、承認処理が遅れてしまい、設定した公開日を過ぎてから実際に公開された」というパターンも発生します。
そこで、上記への対応として「公開日時」列には、公開する直前の値（=utcNow()）を設定しています。
「承認の状況」列を更新
続いて、「承認の状況」列を承認待ち→承認へと遷移させます。
Point：「承認の状況」列を承認待ちへと遷移させる理由
Step4：承認前の処理にて、既に「承認の状況」列を承認待ちへと遷移させたのに、なぜ再度同じ処理を行っているのでしょうか。
それは、プロパティを更新すると「承認の状況」列が自動的に下書き状態に戻るためです。
実際にお試しいただければ理解されるかと思いますが、承認待ちにしたレコードを手動で修正すると、「承認の状況」列は自動的に下書きに戻ります。
これは、Power Automateでも同様の現象が発生します。具体的には、承認フロー内で「プロパティの更新」アクションを実行すると、「承認の状況」列は下書きに戻ります。
また、下書き → 承認という遷移はできず、下書き → 承認待ち → 承認とする必要があります。
よって、再度承認待ちへと遷移させています。
各アクションの設定は以下のとおりです。
アクション名 | プロパティ | 値 |
|---|---|---|
ファイル メタデータの取得：承認後処理 | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/{Identifier}’ |
コンテンツの承認状態を設定します：Submit-承認後処理 | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/{Identifier}’ |
Etag | outputs(‘ファイル_メタデータの取得：承認後処理’)?[‘body/ETag’] | |
outputs(‘ファイルのプロパティの取得：申請’)?[‘body/{Identifier}’ | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/{Identifier}’ |
Etag | outputs(‘コンテンツの承認状態を設定します：Submit-承認後処理’)?[‘body/ETag’] |
通知
申請者や閲覧者へ向けて通知を行ってください。
詳細は割愛します。
Step6：フローにエラーが発生した場合の処理
最後にフローが発生した場合の処理を追加します。
詳細については、以前ブログにて記載しておりますので、以下をご参照ください。
Power Automateのベストプラクティス・アンチパターン(7)【エラー発生時、管理者へ通知する方法】
Point：Power Automateの例外処理
フロー内の処理でエラーが発生した場合は、例外処理を行うことで、問題の早期発見と対処が可能になります。
本処理は、すべてのフローに追加すべきだと思っておりますので、しっかり追加していきましょう。
以上で完成です！
お疲れ様でした！！
おわりに
Sharepointで用いる承認フローを構築しました。
今回重要な点は以下です。
Etagを用いて、編集されたかを確認すべし
Etagを用いると、申請されてから編集されたかどうかをチェックできます。
プロパティを変更した場合は、「承認の状況」列を承認待ちへと遷移させるべし
プロパティを変更した場合は、下書きとなっているため、一度承認待ち（=Submit）へと遷移させましょう。
例外処理を追加すべし
エラーを即座に発見するために、例外処理を付け加えましょう。
本ブログの内容は、サイトのページ（ニュース・ページ）・リスト・ドキュメントライブラリに使える汎用的な承認フローとなっています。
ただし、実際の運用を考えると、以下機能を追加で要望されることもございます。
承認者を動的に変更したい
承認有無を動的に変更したい
承認者が承認していない場合は、承認リマインドを通知したい
内容に応じてセキュリティの設定を変更したい
上記のご要望がある場合は、ぜひアーティサンへご連絡いただければと思います！
💡 SharePointやPower Platformの導入を検討中ですか？
本記事でご紹介した内容以外にも、「自社の業務に合わせた承認フローの設計・運用」や「Power Platformの活用」についてご相談を多くいただいております。
もし「自分たちだけでは難しい」「専門家のサポートがほしい」と感じた際は、アーティサン株式会社のサービスもぜひご活用ください。！
ご相談・お見積りは無料です！
【こちらも合わせて読みたい】
小刀稱知哉
🖊小刀稱知哉さんのブログ一覧はこちら大分県出身（温泉大好き）、現在は茨城県在住
1990年生まれ
30才でメーカーの技術営業からIT業界にジョブチェンジ!!!
趣味は読書（最近書道を始めました）
主にMicrosoftのローコード（SharePoint・Power Platform）に関するに関する営業活動や設計、開発などを担当しております！
（最近はCopilot Studioについても勉強中）
Microsoft MVPを受賞させていただきました！
持ってる資格はPL-200/PL-300/PL-400/PL-600/MS-700/AZ-104/AZ-305/SC-200/SC-100
こんにちは。アーティサン株式会社の小刀稱（ことね）です。