#概要
SharePointリストとPower Automateで簡易承認ワークフローを作成するときの
SharePointの権限設定パターンの覚え書き。

#承認フローの概要
今回解説するパターン

申請内容はSharePointリストに登録。
入力項目は件名、申請日、承認ルート、Excel添付ファイルとする。
申請者は事前に用意された承認者マスターから承認者を選択する。
承認者は、承認依頼からSharePointアイテムへのリンクを開き、SharePoint上で内容確認する。
その他、Automateの実行は、SharePointのアイテム選択→自動化から実行するインスタントフローとします。

準備編

##SharePointの準備

###①承認者マスター
承認者をマスタから選択できるようにするためこちらを先に作成します。
承認者リスト列はユーザー型で複数のユーザーを設定できるようにします。

###②申請管理リストの作成
以下のような列を用意します。
承認ルートは参照型で、①のマスターを参照します。
設定はこちらの記事と同じです。→承認者マスターを使ったSharePoint承認ワークフロー

申請者名列の作成は任意です。
文書を改訂して申請するような要件の場合、承認すると更新者列が上書きされ誰が申請したかわからなくなるため、
Power Automateから申請者名を記録しておくために使用します。
新規登録しかしない申請なら登録者名の列で代用できます。

###承認機能の有効化
申請管理リストについて、バージョン設定から承認機能を有効にしておきます。

また、ビューの設定から承認状態、承認者のコメント列を表示しておきます。

Power Automateの準備

フローの作成

以下のようにスタンダードな承認フローを作成します。
承認者のアドレスリスト生成や承認状態の設定など、フローの細かい内容についてはこちらの記事を参考にしてください。→承認者マスターを使ったSharePoint承認ワークフロー
今回はSharePointリストから起動するインスタントフローです。

「承認を開始して待機」アクションではアイテムへのリンクを設定しておき
承認者がSharePointのアイテムを開いて内容確認できるようにします。

承認結果の判定と承認状態設定は以下のようなフローです。

接続情報の設定

インスタントフローの場合は既定で利用者の接続情報を使用して各アクションの処理を行います。
フローの内容によっては、以下のように接続情報をフロー所有者のものに変更する必要があります。

Power AutomateからSharePointのアイテムを承認するには、「コンテンツの承認状態を設定する」アクションにより明示的に承認しますが、これはSharePoint側の機能です。
承認を実行するには、フローの接続ユーザーにSharePointの「アイテムの承認」アクセス権が必要です。(後ほど解説)

そこで、SharePointの接続情報を承認権限又はフルコントロール権限を持っているフローの所有者にします。
フロー詳細画面にある以下の編集を開き、

SharePointの接続をこの接続(所有者)に変更します。

#SharePointの権限設定パターン
##パターン1 ユーザーにSharePoint承認権限を付与するパターン

下書きの表示は既定の「アイテムの作成者およびアイテムを承認できるユーザー」とするパターンです。
承認待ちアイテムは、申請者本人かSharePointの承認権限がある人しか見えません。
申請内容を確認する人に承認権限を設定しておく必要があります。

###ポイント

投稿者には投稿者(削除制限)権限をつける。
承認者には承認者(投稿者+承認)権限をつける。
承認権限をつけることで標準機能による一括承認も実行可能にする。

###SharePointリストの設定
リストの設定→このリストに対する権限から設定できるアクセス権の設定を行います。
※リスト固有の権限にするかサイトの権限ごと触るかはお好みで。

権限設定に関してはこちらの高田弘介さんの動画が圧倒的に分かりやすいです。
https://www.youtube.com/watch?v=ZxGzFHeTk1Y&t=2195s

アクセス権設定の完成系は以下のようになります。

アクセス許可レベルの作成
まずは独自のアクセス許可レベルを作成します。
アクセス許可とは、投稿者：「投稿はできるけど削除はできない」、承認者：「投稿に加えて承認ができる」といったようにアクセス許可の組み合わせを定義するものです。

サイト設定→サイトの権限画面を開き、アクセス許可レベルをクリックします。

デフォルトで以下のような権限が表示されています。

投稿(削除禁止)権限を作成
投稿権限をもとに作成したいので、「投稿」をクリックしてアクセス許可レベルをコピーします。

削除権限を外し「投稿(削除禁止)」と名前を付けて「作成」で保存します。

承認者権限を作成
更に、先ほどの投稿(削除禁止)権限をコピーして、承認者権限をつけて名前を付けて保存します。

グループとアクセス許可を設定
SharePointグループを編集しグループのメンバーとアクセス許可を割り当てます(適当)
グループの作成は「グループの作成」ボタンから。サイトのアクセス権の画面から設定する必要があります。

グループの呼び出しとアクセス権付与は「アクセス許可の付与」ボタンから設定します。

最終的に以下のようになります。
メンバー：申請するメンバーを設定、投稿(削除制限)権限を設定
承認者：承認者となるメンバーを設定、承認者権限を設定。

特定のSharePointリストだけに設定する場合は、固有の権限の設定を行い、アクセス権の継承を停止します。

その他、Power Automateフローの所有者となる人はSharePointリストの所有者となるよう設定されていることも確認します。
Teamsから作成されたSharePointの場合はチームの所有者にすればOKです。

###動作

申請者がフローを実行すると、承認者に承認依頼が届きSharePointのアイテムを開いて内容を確認します。
下書きアイテムは承認者しか閲覧できない設定ですが、承認者権限を設定しましたので閲覧することが可能です。

その他、両パターン同じですが
フローからの承認処理は所有者の情報を利用しますので、アイテムの更新者は所有者の名前になります。

###メリット
・SharePoint標準の承認機能も使えるので手動で一括承認なども実行できる。

・下書きアイテムは一般の投稿者に見えないようにできる。

###デメリット
・承認権限があれば手動で誰でも承認できてしまう。
・アクセス権を付与するユーザーの管理が面倒。

権限の設定が面倒ですね。
TeamsのSharePointでやるような部内/小規模なものであれば、
承認者をチームの所有者に設定、申請者はチームのメンバーにしてしまう運用が楽ですね。
※チームの所有者はサイトコレクション管理者となります。

##パターン2 承認者のアクセス権設定を使用しない場合
先ほどのように面倒なSharePointのアクセス権を使用しない方法です。

ポイント

承認権限は所有者のみ。Power Automateは所有者権限で承認設定する。
業務上の承認者にはSharePointの承認権限を持たせない。
代わりに下書きアイテムを全員が表示できるよう設定。

###SharePointの設定

①バージョン設定で、アイテムを編集できるユーザーに表示できるようにする。

承認者にはSharePoint承認権限を付与しませんが、このように設定することで誰でも下書きアイテム(承認待ち)を表示できます。
ただし、承認待ちアイテムは他人から編集ができてしまいます。

②詳細設定で、ユーザー本人のアイテムのみ編集できるようにする。

これで承認待ちアイテムは本人以外編集できないようになります。

その他、Power Automateフローの所有者となる人はSharePointリストの所有者となるよう設定されていることも確認します。
リストの所有者はフルコントロール権限となり「承認」権限の他、「リストの動作を無視」といった権限により閲覧・編集の制限を無視できます。

###動作
申請者がフローを実行すると承認者に承認依頼が届き、SharePointのアイテムを開いて内容を確認します。
下書きアイテムは編集権限以上の人が表示できるので、承認権限のない業務上の承認者もアイテムを閲覧できます。
Power Automateから「コンテンツの承認状態を設定する」

###メリット
・難しい権限設定をしなくてもよい。
・標準の承認機能が使えないので、承認者グループで指定された人しか承認できない。

###デメリット
・アイテムの作成者しか編集できないので、既存のアイテムを編集して再申請するようなフローには使えない。
→新規アイテムで申請して終わりのフローなら問題なく、文書管理などの改訂を伴う申請フローには向きません。
・SharePoint標準の一括承認が使えない

#おまけ
Power Automateで承認を作成するアクションを使用すると、承認者に対してメールの他Teamsの承認アプリでも通知が飛びます。
同様に承認アプリでは、申請者側も「送信済み」として申請記録が残ります。

送信済みタブを見ると自分が申請した内容と、申請状況が確認できます。

ここに「リクエストキャンセル」と「フォローアップ」というボタンがあります。
それぞれ動作が以下のようになります。

フォローアップ
クリックすると承認者のTeamsにトースト通知でフォローアップを送ります。
ボタンが一旦グレーアウトしますが、送信が終わると何度でもクリックできるようです。
承認の遅い上司に押しまくりましょうｗ

Power Automateからこのフォローアップを実行できれば悪いことができそうですｗ

リクエストをキャンセル
承認依頼をキャンセルします。
承認者のTeamsには「〇〇が要求をキャンセルしました」という通知が流れます。
Power Automateでは承認を待機アクションを通過します。
テストするとわかるのですがoutcome＝結果や、responses＝回答数（笑）が空白となっています。

フロー内でキャンセルされたか判定するには、条件アクションでempty()関数を使って空判定する必要があります。

参考ですが、承認アクションの要求元は既定では接続情報のユーザーとなります。
インスタントフローでは実行者の接続情報を設定できますが、クラウドフローの場合は所有者の接続情報しか使用できず、承認の依頼元がフローの所有者となってしまいます。
対応方法としては、詳細オプションにある「要求元」にメールアドレスを設定すると、承認の要求者をその人に設定することが可能です。

#あとがき
SharePointの権限設定はあくまで一例です。要件によって他の運用パターンもあるかと思います。
できる限りメンテナンスが単純になるパターンで管理したいですね。

SharePointを使った承認フローの作成方法を教える機会があり、詳しくはこれを見てね、という記事が欲しくてまとめてみました。

'22/2
フローの接続ユーザーの設定に誤りがあり、パターン1が動作しない問題があったものを修正。