平成はお世話になりました。
令和もよろしくお願いいたします。
さて、令和1発目のネタは、PowerAppsとMicrosoft Flow(以降、Flow)を組み合わせる際の「やまだ流 設計思想」について、です。あくまで個人的な思想と、現状の仕様に依存する点はご留意ください。
結論
先に結論を置いておきます。まず、基本方針として。
Flowは作成者のみで動作するよう設計する
どうしても、共有しないとダメって場合があります。その際は。
バックアップをちゃんと確保する。
です。
（´-`）.｡oO（後者が設計じゃないけど、しょうがないね）
PowerApps アプリの共有について
作成したPowerApps アプリを他のユーザーへ利用してもらう場合、アプリの共有が必要となります。実施手段などは公式のDocsをご確認ください。
PowerApps のアプリ共有に関しては３つの役割が存在します。
| 役割 | 概要 | |
|---|---|---|
| 1 | 所有者 | アプリを作成したユーザー。 ※GUIによる権限変更や所有者追加は不可 |
| 2 | 共同編集者 | アプリの使用、編集、共有は可能。 アプリ自体の削除、および所有者の削除、変更は不可 |
| 3 | ユーザー | 利用者。設定の変更は実施不可 |
適切な役割を指定することにより「アプリを編集してもよいメンバー」「単純に利用者として指定したいメンバー」が明確に管理できます。なお、この設定はアプリ自体に対するものであり、データソースに対しては影響しません。そのため、データソースに対しては個別の権限設定が必須となりますので、ご注意ください。
アプリの所有者を変更するには？
記事投稿時点ではGUIからの変更はできないようです。PowerApps 用のPowerShellを利用ください。
PowerShell Cmdlets for PowerApps and Flow creators and administrators
業務利用するようなアプリに関しては「ほぼ間違いなく削除しないであろう専用ユーザーでアプリ所有者をすべて集約する」ようにしてしまえば、こんなコトは考えなくてよいかな、と個人的に思っています。アプリ作成時はSharePointのサイトを作成するなど、PowerAppsアプリ作成者の役割だけでなくOffice 365管理者権限が必要になることも多々あると思いますので、ぜひアプリ専用ユーザーを用意されるコトをお勧めします。※もちろんライセンスが1つ必要になりますが運用などを集約できるメリットとコストを比較くださいませ。
Microsoft Flow の共有について
FlowもPowerApps同様に、他のメンバーへ利用してもらう場合は共有が必要になります。手順はPowerAppsと殆ど同様です。
共有手順はPowerAppsと殆ど同じなのですが、役割が全く異なります。Flowは「所有者の追加」（所有者として他メンバーを追加する）しかできないのです。
何が問題なのか？
Flowを共有した場合、共有された全てのメンバーに、そのFlowを編集・削除することが可能な権限が付与されます。つまり、操作ミスなどによって、せっかく作ったFlowを破壊される可能性がある、ということです。
残念なことに、Flowには記事投稿時点で履歴管理の仕組みがありません。つまり、破壊されたら一巻の終わり、ということです。
なお、PowerAppsには履歴管理の仕組みが提供されています。
対策は？
冒頭の結論どおり、Flowを作成者のみ（または必要最低限の範囲）で動作するように設計する、というのが1つ目の案です。PowerApps アプリ所有者を変更する箇所でも提案していますが、アプリ専用ユーザーへFlowの作成者も集約してしまえば良いかな、と個人的には考えております。
共有しないとダメなパターンは業務上発生しますので、その際は「あきらめる」というのも2つ目の案になります。ただし、破壊される可能性があるので、適宜バックアップを取得する等の対策が必須になります。
対策1：Flow実行ユーザーを限定する設計
下記のようなアプリを作成する場合を考えてみます。
■仕様
1. PowerAppsで写真を撮影する
2. データストアはSharePoint Online
（カスタムリストとドキュメントライブラリ）
3. 新規アイテムが格納されたら管理者へメールとTeams通知する
ファイルアップロードと通知はFlowで実装したほうが楽そうです。さて、この場合、設計・実装としては大きく2つの選択肢があると思います。
選択肢1：PowerAppsから直接Flowを呼び出して通知
選択肢2：SharePointの新規登録トリガーで着火するFlowで通知
残念ながら、PowerAppsから撮影した写真などをアップロードする場合などはFlowを組み合わせて直接起動する必要があります。そのため、仕様1にならざるをえません。選択肢1で実装した場合は説明した「Flowを共有した場合のリスク」がそのまま適用されます。PowerAppsからFlowを直接利用する場合は、両者ともに利用者全てに共有する必要あるからです。
通知に関しては、選択肢2で実装すべきと常々思っているんですよね、自分は。選択肢2であれば、Flowは作成者以外に共有する必要がないのです。ざっくりとイメージにすると下記。
基本的に、PowerAppsとFlowを組み合わせる場合は、上記のような設計になるようにしています。
対策2：あきらめてバックアップ運用する
PowerAppsとFlowを組み合わせるしかない処理（例えば前述のファイルアップロード）もあります。その場合は、Flowを適切にバックアップしておくしか逃げ道がありません。
Microsoft Flowの設定をエクスポート・インポートしよう
ソリューションをエクスポートする
幸いにも、すべてクラウドの仕組みなので、OneDrive や SharePoint へバックアップを格納しておけばインターネットさえ接続できれば復旧は簡単です。
え？
対策1で設計・実装してもバックアップって重要じゃないか？って？
正解です！転ばぬ先のバックアップ、重要ですね( ´∀｀)bｸﾞｯ!
まとめ
- PowerApps は役割(権限)で利用の影響範囲を管理できる
- Flow は役割(権限)が「所有者の追加」なので注意
- 共有された側は、そのFlowを編集できる
- 誤って破壊される等のリスクが存在する
- 共有された側は、そのFlowを編集できる
- Flow は可能な限り共有せず、作成者のみで動作するよう設計すべき
- どうしてもFlowの共有が必要な場合はバックアップ必須
- ※共有しなくてもFlowのバックアップは実施推奨
- アプリ専用ユーザーで運用すると楽かもしれないぞ
Flowにも、PowerAppsのように「ユーザー」（実行しかできない）という役割(権限)があれば色々と安心感があるのになぁ、と思っております。あと、LogicAppsにはある履歴管理がFlowにも提供されると最高だなぁ、と思った令和初日。（いや、それ以前から思ってるけどｗ）
個人的に現状でとれるベターな案がコレだと思っているのですが「こっちのほうが効率的だよ」みたいな案があれば、ぜひご教授賜りたいです。その際はDM等でご連絡いただけると幸いです。
それでは、皆さま。令和も素晴らしい Power Platform Life を！