アプリ開発の調査にかかる
時間を削減したい
内製化支援サービス
アプリを自分たちで
作成できるようになりたい
DX人材育成プログラム
プロに開発を依頼したい
アプリ開発導入支援サービス
機能拡張サービス
X-SP Feature
デザイン拡張サービス
X-SP Design
モダン化から運用管理までサポート
構築支援サービス
SharePointで社内ポータルサイトを構築する際、「申請・承認プロセスを自動化したい」といったご相談をよくいただきます。
Power AutomateはMicrosoft 365に含まれるローコード自動化ツールで、SharePointと連携してさまざまな業務フローを自動化できます。
本記事は、Power Automateの基本操作（例：フローの新規作成やトリガー・アクション追加）ができる方を想定していますが、
「Power Automateは使ったことがあるけど、SharePointとの連携や承認フローは初めて」という方にも分かりやすいよう、段階的に手順やポイントを解説します。
デフォルトのPower Automate承認フローをそのまま使うこともできますが、実運用では「保守性」「柔軟な運用」「エラー対応」などの観点から、自社に最適な承認フローを設計・構築することが大切です。
特に、実運用に耐える承認フローを作るには、要件に合わせたカスタマイズや将来的な保守性を意識した設計が不可欠です。
しかし、いざカスタマイズしようとすると
「どこから手をつけて良いかわからない」
「エラーの原因特定や対処法がわからない」
「意外と設定が複雑」
といった課題に直面することも少なくありません。
また、承認フローの大まかな部分については簡単に作成できますが、本当に重要なのは「実運用に耐えうる処理とする」ことや「保守性の高い」フローを構築することです。
そこで今回は、SharePointの承認フロー構築において重要な設計の考え方と、実運用を見据えた具体的な実装方法を、実際のフロー構築例とともに詳しく解説します。
また、関連する実践的なブログ記事もご紹介しますので、実運用・保守性を意識した承認フローの作り方を知りたい方はぜひ参考にしてください。
前回のブログについては、以下をご参照ください。
もし記事を読んで
「自社でも承認フローを導入したい」「もっと効率的な運用方法を知りたい」と感じた方や、
具体的な設計・構築でお困りの方は、アーティサン株式会社の各種サービスもご活用いただけます。
現場の課題やご要望に合わせて、SharePointやPower Platformの導入・運用をサポートしていますので、ぜひお気軽にご相談ください。
前回は、SharePointで承認フローを構築するための事前準備について説明しました。
今回は、承認フローの構築について説明します。
今回の要件
改めて、今回の要件ついて説明します。
要件
SharePointサイト内で作成した各種リソースについて申請・承認機能（承認フロー）を実装する
対象は以下
サイトのページ（ニュース・ページ）
リスト内のアイテム
ドキュメントライブラリ内のドキュメント
承認者は固定
必要に応じて、申請者や承認者、サイトの閲覧者に通知する
実運用・保守性を考慮した設計とする
構築した承認フロー
全体像イメージ
※注意※
以下のフローは、ドキュメントライブラリ用に作成しています。
サイトのページ（ニュース・ページ）やリストアイテムの場合適宜読み替える箇所がありますが、詳細についてはフローを説明する中で紹介します。
承認フローの構造
承認フローの構造としては、全部で6ステップに分割することができます。
各ステップでの内容は以下の通りです。
トリガー
フローを起動する際のトリガーです。
準備
値を取得するアクションや変数の定義を行います。
「値を取得するアクション」の必要性については、以下ブログに記載しておりますので、ご参照ください。承認前の処理
承認依頼を出す前に行う処理です。
今回は、申請されたレコードに対して、プロパティ（申請者・申請日時）を追加する処理を行っています。
また、今回は実装していませんが、承認者をマスタから検索するという処理も、こちらに入れる場合があります。承認の処理
承認の処理です。
承認者に対して、承認依頼を通知します。承認後の処理
承認された後の処理です。
今回は、指定された公開日時まで待機する処理や、
申請されたレコードに対して、プロパティ（公開日時）を追加する処理を行っています。
また、公開された際には申請者やサイト閲覧者に対して通知する処理も実装しています。フローにエラーが発生した場合の処理
フロー全体でエラーが発生した場合の処理です。
考え方などについては、以前ブログを作成しておりますので、こちらもご確認ください。
以降の章では、各ステップごとの詳細について説明していきます！
Step1：トリガー
まずはトリガーの設定です。
※承認対象がサイトのページ（ニュース・ページ）の場合は、前回のブログで、既に作成しておりますので、本項目は不要です。リスト・ドキュメントライブラリの場合はフローを新規作成し、トリガーを設定してください。
トリガーの種類
リストの場合：インスタントクラウドフロー > 選択したアイテムの場合
ドキュメントライブラリの場合：インスタントクラウドフロー > 選択したファイルの場合
補足
申請時に入力したい情報がある場合は、トリガーの「入力の追加」から設定することも可能です。
Step2：準備
準備ステップの目的
後続処理で必要な値を「取得アクション」で取得しています。
また、変数の初期化も行っています。
なぜ「値の取得」アクションが必要？
トリガーで得た動的コンテンツを後続アクションで使用する場合、トリガーが変更となった際に変更する影響範囲が大きくなってしまいます。
詳細はこちらの解説記事をご覧ください。
アクションの種類はリソースによって異なります。
アクションの種類
サイトのページ・リストの場合：SharePoint > 項目の取得
ドキュメントライブラリの場合：SharePoint > ファイルのプロパティの取得
また、今回は以下2つの変数を用います。
変数名 | 種類 | 設定値 | 備考 |
|---|---|---|---|
finishLoop | ブール値 | false | 後述するDo Untilループの制御を行う際に用いる |
申請日時 | 文字列 | formatDateTime(utcNow(), ‘yyyy-MM-ddTHH:mm:ssZ’) | 申請日時を保存 |
Step3：承認前の処理
続いて、承認前の処理です。
本ステップでは、承認依頼を出す前に行いたい処理を記載します。
例えば、以下のような処理です。
申請されたレコードに対して、自動的に値を追加したい。
申請された情報から承認者を動的に設定したい。
今回は「申請されたレコードに対して、自動的に値を追加する」処理として、「申請者」列と「申請日時」列に対して、承認フローの中で追加しています。
Point：申請者や申請日時を別の列として準備したほうが良い理由
皆さんの中で、申請者や申請日時をなぜ別途準備する必要があるのか？と思われる方はいらっしゃいませんか？
仰るとおり、申請者は更新者を見ればわかるし、申請日時も更新日時を見ればわかるかもしれません。
ただし、実際の運用を考えた際、上記ではうまくいかないことがあります。
それは、誰かがデータを編集した際、自動的に更新者や更新日時が上書きされてしまうことに起因します。
値が上書きされてしまうと、申請者や申請日時が想定している値とは異なる可能性があるため、別途準備しています。
本ステップでの具体的な処理は以下となります。
プロパティの更新
「ファイルのプロパティ更新」アクションで設定してる値は以下です。
アクション名 | プロパティ | 値 | 備考 |
|---|---|---|---|
ファイルのプロパティの更新：プロパティの更新 | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/ID’] | |
申請者 | triggerOutputs()[‘headers’][‘x-ms-user-email’] | フローをトリガーしたユーザーのメールアドレス | |
申請日時 | 申請日時の変数 |
Point：なぜDo Untilを用いるのか
プロパティを更新する際、Do Untilアクションを用いているのでしょうか？
皆さんDo Untilを用いずにファイルのプロパティ更新を行った際、「XXによってロックされています」というエラーが表示されたことはありませんか？
申請後もファイルやニュースを開いている際などに上記のエラーが発生します。
そこで、Do Untilを用いてリソースを定期的に確認し、ロックが解除されるまで待つように処理を追加しているわけです。
（私の経験上、大体5～15分程度待てばロックが解除されることが多いです。）
2つの「条件」アクションで設定している条件は以下のとおりです。
アクション名 | 左辺 | 式 | 右辺 |
|---|---|---|---|
条件：共有ロック状態の場合は、待機させる | body(‘ファイルのプロパティの更新：プロパティの更新’)?[‘message’] | 次の値を含む | によってロックされています |
条件：正常終了すればループ終了 | outputs(‘ファイルのプロパティの更新：プロパティの更新’)[‘statusCode’] | 次の値に等しい | 200 |
「条件：共有ロック状態の場合は、待機させる」アクションでは、共有ロックエラーのチェックを行っております。
「条件：正常終了すればループ終了」アクションでは、ファイルのプロパティ更新が正常に終了したか確認し、正常終了の場合はDo Untilを抜けるようにしています。
また、上記2つのアクションに関しては、実行条件の構成についても設定変更しています。
「条件：共有ロック状態の場合は、待機させる」アクションでは、「ファイルのプロパティの更新」アクションが正常終了しなかったときに実行されます。
また、「条件：正常終了すればループ終了」アクションは、すべての場合において実行されるように設定しました。
これにより、以下の処理を実現することができます。
→ 共有ロックの場合は待機 → 再度「ファイルのプロパティの更新」アクションを実行 → …
「ファイルのプロパティの更新」アクションが正常終了
→ Do Untilループを抜ける
「承認の状況」列を更新
プロパティを更新した後は、「承認の状況」列を承認待ち状態に遷移させます。
各アクションで設定してる値は以下です。
アクション名 | プロパティ | 値 |
|---|---|---|
ファイル メタデータの取得：承認前処理 | ファイル識別子 | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/{Identifier}’] |
コンテンツの承認状態を設定します：Submit-承認前処理 | ID | outputs(‘ファイルのプロパティの取得：申請’)?[‘body/ID’] |
Etag | outputs(‘ファイル_メタデータの取得：承認前処理’)?[‘body/ETag’] |
おわりに
少し長くなってしまいましたので、今回はここまでとさせていただきます。
今回ポイントとして挙げたのは以下です。
申請者や申請日時を別の列として準備するべし
実際の運用を考えた際、「更新者」列や「更新日時」列では想定外の値が入る可能性があるため、別途列を準備しましょう。
プロパティの更新時は、Do Until内で対応するべし
共有ロックに関するエラーを防ぐため、プロパティを更新する際にはDo Until処理を入れましょう。
今回は、承認フローについて、トリガー → 準備 → 承認前の処理まで作成いたしました。
次回は、承認の処理以降を作成し、フローを完成させます！
💡 SharePointやPower Platformの導入を検討中ですか？
本記事でご紹介した内容以外にも、「自社の業務に合わせた承認フローの設計・運用」や「Power Platformの活用」についてご相談を多くいただいております。
もし「自分たちだけでは難しい」「専門家のサポートがほしい」と感じた際は、アーティサン株式会社のサービスもぜひご活用ください。！
ご相談・お見積りは無料です！
【こちらも合わせて読みたい】
小刀稱 知哉ことね ともや
得意領域
Power PlatformやSharePointを中心に設計・開発・アドバイス・教育まで幅広く担当しています。内製化をご希望の場合はお気軽にお問い合わせください！
保有資格
こんにちは。アーティサン株式会社の小刀稱（ことね）です。