★2024/2月更新 YouTubeに登壇動画アップしました！
人気の高い本記事ですが、本記事の内容のもととなった登壇資料をYouTubeチャンネルを立ち上げて動画アップしました！併せてご視聴ください～！
はじめに
Power AppsとPower Automate(クラウドフロー)は仲良しなので、よく連携をしてシステムを構築します。
その際のパターンと違い、気を付けるポイントとV2トリガーのおすすめなどを記事にしました。
アプリからフローへ連携するパターン
アプリとフローを連携するパターンとしてはおおむね以下でしょうか。
- アプリからフローを呼び出し
- アプリでデータソースを更新しデータソース更新をトリガーにフローを起動
上記はどのユーザーで実行されるか異なる点がポイントとなります。
また②ではタイムラグがある点もポイントですね。
①のアプリから呼び出す場合はさらに、アプリ操作者とフロー作成者の2パターンになります。
TIPS以前（といっても2年くらい前）まではアプリから呼び出す場合は実行者の接続となる仕様でしたが、
Power AppsトリガーV2を使えば使用する接続の変更が可能となります。
| 連携パターン | フローの各コネクタの接続 | ポイント |
|---|---|---|
| ①アプリからフロー呼び出し ー１ | アプリ実行者 | 通常はアプリから呼び出すとアプリ操作者となる |
| ①アプリからフロー呼び出し ー２ | アプリ実行者 OR フロー作成者 | ★Power AppsトリガーV2を使用すれば接続の変更が可能！ |
| ②データソース更新トリガー | フロー作成者 | ★ライセンス、データソースに応じてタイムラグあり |
NOTEその他にもアプリを使わないケースで、SPOリストから直接フローを呼び出し
（ビューにボタン追加）などの方法もありますが、今回はアプリを使用する前提なので割愛します。
また、①アプリからフローを呼び出す場合は、結果をアプリに戻すパターン、戻さないパターンもありますね。
こちらはまた別の記事でご紹介しようと思います。
データソース更新トリガーの場合
先に②データソース更新トリガーの場合について（おもにSPOリストと思います）
- 実行はフロー作成者の接続となる。（アプリの操作者の接続ではない）
- ポーリングトリガーなのでタイムラグがある（SPOリストはM365ライセンスは最長5分、有償ライセンスなら1分）
①については、作成・更新時トリガーやスケジュールで動くフローの場合はフロー作成者の接続が使われます。
アプリとは別で動作しているので当然といえば当然ですね。
おおむねリストなどへ管理者権限があるユーザーが作成するので、大体の処理は権限の問題なく動作すると思います。
ただ、メールを送信する場合などは送信者（FROM）はフロー作成者となります。
NOTEこの点は実行ユーザーと関係ない作成者がFROMになると困惑しますので、以下のような対応を取ることが多いと思います。
１．システムアカウント的なユーザーを用意して作成者にする
２．共有メールボックスを使用して送付する（メールボックスに対して操作できる権限が必要）
②については、SPOリストの自動フロー(作成や更新時のトリガー)は、最長5分間のポーリングで動作します。
要は5分に一回チェックしてその際に実行するので、平均では2，3分くらいかと思います。
上記のタイムラグがネックとなる場合などはアプリからフローを呼び出すようにしよう！
となりますが、普通にやるとアプリ操作者の接続になるので注意が必要です。
ポーリングトリガーの件はMVPたなさんが詳しく書いてらっしゃったのでこちらご参照ください。
アプリからフローを呼び出し
アプリからフローを呼び出す場合はタイムラグはなくすぐに実行されます。
ただ、上記でも記載しましたが、従来のPower Appsトリガーの場合は、フローで使用される各コネクタの接続は必ずアプリ操作者となります。
そのため、アプリ操作者が各データソースなどに対して適切なアクセス権を持っている必要があります。
アプリから呼び出してSPOリストを更新する場合は操作者が更新者となりますが、
アクセス権によっては操作できずエラーとなるケースがあります。（権限設定など）
また、メール送信時のFROMはアプリ操作者となります。そうしたい場合は良いですが、
逆に共有メールボックスを使ってメールを送信したい場合には、アプリを操作するユーザーすべてに共有メールボックスに対して操権限を付けないとエラーとなります。
上記は初学者の方は結構つまずくポイントかと思います。
作ったアプリが作成者では動くが他ユーザーではエラーとなり使えない。というようなことが起きます。
せっかく作ったアプリとフローが、公開したら他の人ではエラーになっちゃうって話よく聞くわ！こういうのが原因なのね！
Power Apps (V2)トリガーを使おう！
そこでPower Apps(V2)トリガーを使うことをお勧めします。
今からもう2年位前の2021年の夏ぐらいからPower AppsトリガーのV2が出ています。
こちらのトリガーの場合は、実行時に使う接続を指定することが出来ます！
TIPS2023/12月追記
無印版のPower Appsトリガーは10月ごろから非表示になりました。なので基本はV2を使う一択ですね！
当時も自社ブログへ書いてますが、従来のPower Appsトリガーでは、
トリガーは定義せずアクションで使用すると自動作成される、名前変更は不可、うまく消せないなどの挙動があり、個人的には使いずらかったです。
V2では他の手動トリガー（インスタントフロー）同様に、パラメータ、型、必須・任意などの定義が可能で使いやすくなっています。
その他デメリットもない（と思う）から、
Power Apps (V2)トリガーを使う一択だね！
実行する接続の変更
Power Apps (V2)トリガーの場合、フローの詳細画面で「作成者の接続」 OR 「実行ユーザーの接続」 のどちらを使うかを選択が出来ます。
既定は実行ユーザーの接続になっています。
この部分は他のインスタントフローは従来から可能でしたが、従来のPower Appsトリガーではその設定がなかったのです。（設定画面自体が表示されない）
上記の部分で各コネクタの実行時の接続を選択して変更ができます。
また、SPOは作成者の接続にして、ExcelOnlineや承認アクションは実行ユーザーの接続とする。
など、コネクタ単位ごとに変更ができます。
TIPSアプリから接続しているフローは、アプリを共有すればフローは自動的に「実行のみのユーザーとしての共有」がされるので、この画面でアクセス権を付けてあげる必要はありません。
上記をうまく設定すれば、SPOリストの権限設定を管理者権限で実施して、メールはアプリ操作者として送信する。
等の調整が可能です。SPO更新時トリガーと異なりタイムラグもありません。
アプリフローへの連携のサンプルパターン
ケース１：SPOリストへアプリからアイテムを登録して、そのままアイテム単位の権限設定をする
アクセス権限を操作するにはSPOリストに対して権限変更が可能な強い権限を持っている必要があります。
従来版のトリガーでは実行ユーザーの接続 （＝ユーザーのSPOリストに対するアクセス権限）で動きます。
通常、一般ユーザーにはそのような強い権限は与えないので、普通のユーザーが操作した場合はエラーとなります。
SPO更新時トリガーのフローで実装すればフロー作成者（SPOリスト管理者権限あり）で動作しエラーは解消できます。
ただしこの設計の場合は同期的な実装ではないため、上記の通りタイムラグが生じるネックがあります。
フローの処理が実行されるまでは他の人にも見えてしまうためアプリ側でも調整するなどの考慮が必要ですし、そもそもタイムラグが許容されないようなケースもあります。
Power Apps (V2)トリガーを使った場合は、（SPOに管理者権限のある）作成者の接続を使う。
とすれば、アプリの実行ユーザーに強い権限がなくても、権限の変更操作がタイムラグなしで出来るようになります。
以下がそれぞれの設計イメージです。
NOTESPOリストのアイテム単位の権限設定は大規模なリストでは推奨されてません。
上記は前提としてその点をクリアできる要件での設計となります。
SharePoint の制限 – Service Descriptions | Microsoft Docs
従来版トリガーでやると一般ユーザーでは実行できずエラー
別フローでSPO作成時トリガーで実施すればOKだがタイムラグが発生
V2トリガーでSPO接続を管理者にすればタイムラグなく実行できる
ケース２：アクセス権がないリストを管理者として操作する
フロー内で作成者（管理者）の接続を使うようにすれば、SPOリストやファイルなどに対して実行ユーザーに全く権限がない場合でも管理者として操作することが出来ます。
利用シーンとして、ログを保存する管理者用のリスト（一般ユーザーにはアクセスさせたくないリスト）へのアイテム登録時や、一時的に利用するライブラリ（処理後はファイルを消すためユーザーに権限を付けたくない）などの場合にフロー経由で作成者として登録させる。などがあるかと思います。
この場合一般ユーザーにはデータを表示させる必要もなく、出来れば権限を与えたくないのでマッチするかと思います。
※タイムラグが影響なければSPO自動トリガーの実装でも問題はなし
さらにはフローを介してアイテムを取得、更新しアプリ側に表示する設計・実装とすれば、アプリを操作するユーザーにSPOリストにアクセス権限を付けなくても扱えるシステムも構築出来ます。
ただ、閲覧権限すら与えない場合は、データをアプリで表示させる部分もすべてフロー経由で取ってくる必要があるので、フローの同時実行制限やAPIコール数などの点で各閾値を超えてしまう可能性がありますし、そもそも実装が大変（フローからのデータ返却部分など）であったり、他の面での制限が出てくるかもしれないので、セキュアな実装が最優先、かつ、他の課題をクリアできる場合に限られるのかと思います。
やるとしても閲覧権限までは付与しておき更新の部分のみフロー経由で作成者として行う。
あたりまでが現実的な気がします。※合わせてリスト非表示とするなどで工夫
TIPS※従来版トリガーの場合でも、子フローの実行を使って作成者として操作させる実装もできますが、ソリューション内でのみ利用可能な機能なため、組織によっては利用できないケースもあります
NOTE★2023年7月時点では、APIコール数のカウント（M365ライセンスだと1日6000回まで）は接続に指定したユーザーに集中するのかと思いきや、以下公式を見ると利用する接続に関係なく実行者となるようでした。（フロー内での接続関係ないアクションもあるので確かにそうかも）
この辺は移行期間中でレポートも公開前なので、はっきり結果がわからないのでなんとも言えずです。気になる方はＭＳ問い合わせいただくのが良いかと。
Power Automate ライセンスに関してよく寄せられる質問 – Power Platform | Microsoft Learn
その他のケース
その他、Outlookのメール送信やTeams投稿、承認アクションなど各種アクションをあえてフロー作成者として操作させたい場合などもあるかと思います。
共有メールボックスを使用してメール送信したいが、その共有メールボックス自体への権限を与えなければいけないため、作成者の接続で動作させるなど
前途したとおり、SPO、Outlook、ExcelOnlineなどのコネクタ単位で変更できるため、
SPOのみを作成者としてメールはアプリ操作者で送信するなどの調整が可能ですね。
ケース１、およびケース2を合わせたサンプル
以下はアイテム登録後にそのまま権限設定して管理用のログリストへ登録するサンプル実装です。
もちろんライセンスは必要です
作成者の接続を使とSPOやExcelOnlineのライセンスがないユーザーでも使えるのでは？と思われるかもしれませんがそれは出来ません。
アプリにはフローとの接続情報が定義されていて、アプリ初回起動時にはフロー内で使用するコネクタの接続認証が表示されます。
ライセンスを持っていないとこの時点でアプリを利用することが出来ません。
おわりに
今回はアプリとフロー連携の記事でした。
アプリから呼び出す場合と自動トリガーで実行する場合との違いについてと、V2トリガーのおすすめと設計サンプルという感じでした。
どういった設計にするかはケースバイケースなので、V2トリガーが絶対推奨というわけではないです。
使用する接続の変更は記載したようなメリット・デメリットがあるので要件に合わせて設計・実装のご参考にしていただければと思います。
その②ではアプリからフローを呼び出して結果を返却する際のパターンやポイントについて記事にする予定です。それでは。
関連記事
※2023/8/18 続きの記事をアップしました。
Power AppsとPower Automate(クラウドフロー)は仲良しなので、よく連携をしてシステムを構築します。 その②ではその際のアプリからフローを呼び出す、フローへの返却についての内容です。...
Power Automate クラウドフロー（まだ記事少ないですが徐々に増やしてます）
Power AppsときどきAutomate。初学者からその先へ進む方向けのワンランク上の技術情報ブログです。
この記事は役に立ちましたか？
もし参考になりましたら、下記のボタンで教えてください。
コメント