部署異動の際の Power Apps や Power Automate の引継ぎについて


# はじめに

これまで、作成した Power Apps のアプリや Power Automate フローに共同所有者を追加する方法等について書かれている記事もあるという認識ですが、部署異動の時期だと思うので、改めて情報を整理してみたいと思います。

# 方針決め

まず、部署異動の際、元々の作成者について、 Power Apps のアプリや Power Automate フローの所有権限を削除するのか、つまり、アクセス権をはく奪してアクセスできなくするのか、あくまで、引継ぎ先の人を共同所有者を追加するだけに留めるのか、方針を決める必要があると思います。

こちの方針により実際に行うことが変わってきます。特に決まっていない場合はこれから書く内容も踏まえ、どちらにするか判断するのでも良いかと思います。

個人的には、余程の事情がなければ、元々の作成者も所有者として残しておく方法の方がいいと思います。

:::note
これから記載する方法である程度のことは出来ますが、ミッションクリティカルなアプリやフロー、秘匿性の高いようなアプリやフローについては、出来るだけ人の異動や退職に左右されないアカウントで作成しておくことをお勧めします。

また、そうでない場合においても、異動や退職後も継続して使うことが想定される、引継ぎが発生する可能性のあるアプリやフローについては、出来るだけあらかじめ共同所有者を追加しておくルールにしておくことをお勧めします。
:::

# Power Apps アプリの引継ぎ

## 共同所有者を追加する (元々の作成者も所有者として残す)

こちらは簡単です。作成したアプリを利用者に共有するときと同じような操作で、[共同所有者] にチェックを入れるだけです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/492057ca-ef64-e6e9-5f9d-eb7d7515685a.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/ada03755-430c-236c-6296-d1ee61ef1069.png)


:::note
現在、アプリの共有画面が新しくなっています。以下の [クラシック共有を使用する] を選択すると、これまでと同じ共有画面になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/44b157f9-d484-4b12-8a61-4bd164754faa.png)

:::

こちらにより、共同所有者に追加されたユーザーは、[自分と共有] からアプリを探し、編集することが出来ます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/c668c86c-8bc0-2fd8-9265-2d08b6e28c9d.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/41915eea-e1c8-0868-de00-2e1a60a83553.png)

:::note warn
アプリで利用するコネクタ、データソースに対しても同等の権限が必要です。例えば、アプリで利用する SharePoint リストに対して、共同所有者に権限が付与されていない場合、アプリ編集時に以下のようなエラーが発生します。もちろん、アプリを実行した際にもデータソースに接続が出来ず、問題が発生します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/93e422a7-f49e-9c6e-b938-c723ea9418da.png)

:::

## 元々の作成者の所有者権限を削除する

共同所有者を追加すれば、アプリのメンテナンス等は問題なく行うことが出来、また、最悪、元々の作成者が退職をしてアカウントがなくなってしまっても問題なくアプリのメンテナンス等は可能です。

:::note
実は、私も、マイクロソフト退職時、自分が作成したアプリについて、共同所有者を沢山追加して、そのまま退職しました。私のアカウントは削除されたと思いますが、(今も業務上必要であれば) きっと今も稼働していると思います・・・
:::

**もし、部署異動に伴い、どうしても、元々の作成者のアプリのアクセス権を削除したい場合、残念ながら、市民開発者の方が簡単に行う方法はないという認識です。**

個人的に考えられる方法は以下の 3 つです。

### PowerShell コマンドレットを使用してアプリの所有者を変更する

以下のような PowerShell コマンドレットを使用することで、アプリの所有はを変更可能です。変更後、新しい所有者が、旧所有者のアクセス権を削除します。

https://learn.microsoft.com/en-us/powershell/module/microsoft.powerapps.administration.powershell/set-adminpowerappowner?view=pa-ps-latest

```
Set-AdminPowerAppOwner -AppName "922308e9-2ead-4bc2-b89f-95bbc2f4589c" -EnvironmentName "594275cd-68f8-4b7c-8aa3-1dd7d13c6310" -AppOwner "2b55ff59-fa14-4a8e-9337-b1e4d4a52e9b"
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/01c3120c-33e8-f7bb-236f-bc82469685a7.png)

見てわかる通り、全て GUID という、恐らく市民開発者の方からしたら暗号のような形式で指定する必要があり、この GUID をどうやって調べるのか含め、こちらを多くの市民開発者の方に、部署異動時にやってもらうことは、現実的ではないと思います。

### CoE スターターキットを用いてアプリの所有者を変更する

いくつかの記事でも触れた CoE スターターキットという、Power Platform の管理業務等を効率化するアプリやフローの詰め合わせがあるのですが、こちらのアプリの中に、「Set App Permissions」というアプリがあり、アプリの所有者を変更することが可能です。

https://learn.microsoft.com/ja-jp/power-platform/guidance/coe/starter-kit

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/d757a166-11fe-33c3-8964-061ba4136c77.png)

ただし、こちらは、組織に CoE スターターキットがインポートされていることや、その上で、管理者に依頼をする必要があります。

市民開発が浸透しており、多数のアプリがある場合、部署異動時期に、全てのアプリに対してこのような処理をするのは、市民開発者、管理者共に負担が大きいと考えます。そのため、個人的には、あくまで、どうしても元の所有者から権限を完全に削除したい場合の最終手段くらいに捉えておいた方がいいかなと思います。

### アプリを複製して新しい所有者に割り当てる

こちらは、アプリ自体を複製して、つまり、別アプリとして作成するというアプローチです。当然、パッケージやソリューションという単位で、zip ファイルとしてアプリをエクスポートして、引継ぎ先の人にインポートしてもらい、エラー有無など諸々チェックをしてアプリを再リリースする必要があります。

もちろん、アプリの URL も変わります。広く利用されているアプリの場合、再周知が必要になるなど、正直、色々大変だと思います。

そのため、個人的には、あまり広く使われておらず、アプリの URL 等が変わっても特に問題ないアプリにおいて、どうしても元の作成者の権限をはく奪したい場合の手段くらいに捉えておくのが良いと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/67fadbc0-85b8-7fd6-b727-99c7b706a1e6.png)

# Power Automate クラウドフローの引継ぎ

## 共同所有者を追加する (元々の作成者も所有者として残す)

Power Automate に共同所有者を追加する方法も以下のように共同所有者を追加する感じになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/e51e1467-a5a7-0a94-bab9-ebda22a4207e.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/6f06f379-977f-402f-c7cc-98d520c81ea7.png)

追加をすると、追加された側にて、[自分と共有] から、共有されたフローを編集可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/9fd7d102-016c-1443-8d45-dd656a50c501.png)

このままでも問題なく動作しますが、元の作成者が作成した接続情報でフローが色々と動作するのはあまりよろしくないため、引継ぎ先の人がフローを編集し、各コネクタのアクションの接続にて、[新しい接続参照] より、再度認証をしてあげた方が良いと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/e76fe0e9-cad4-b97c-5c86-010f307e76a8.png)

## 元々の作成者の所有者権限を削除する

まず、ソリューション内に作成されたフローであれば、以下の方法で、所有者を変更できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/ee4e0ece-14cd-2c0d-86c3-2ec908e15378.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/2c8f44f5-0509-b900-80b9-31f12670252a.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/adf3136b-69a9-8dc2-0df1-998fad17bd1a.png)

https://learn.microsoft.com/ja-jp/power-automate/change-cloud-flow-owner#change-the-owner-of-a-solution-aware-cloud-flow

しかし、ソリューションに含まれていないフローの場合、共同所有者として追加は出来ますが、元々の作成者の権限はく奪は出来ないです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/c63e7039-7c76-8f6c-8b59-9a823e92691f.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/d1d9f2f9-bdf3-3e21-8c4c-06dde51c1571.png)

:::note
ソリューションについては、以下の記事を参考にしてください。

ただし、「既定の環境」では管理者以外のユーザーはソリューションに対する権限が不足しています。また、全ユーザーが同じ環境でソリューションを利用し、アプリやフローを作成する際にエクスポートやインポートを行うと、意図せずソリューションが上書きされるなどの混乱が生じる可能性があります。

そのため、この方法は 個別の環境 でソリューションを利用して開発する場合の選択肢の一つであり、部署異動時の引き継ぎなど、すべてのケースで適用できるわけではない という点に留意しておくべきだと考えます。

今後、作成されるアプリやフローについて、既定でソリューションに含まれるような動きもあるため、この辺はちょっと難しいところですが、今回は、あくまで、部署異動の際の引継ぎという観点がメインのため、これ以上は深堀しないことにします。
:::
https://qiita.com/skuramoto/items/bb053bdc8b12b771c6e4

なお、Power Apps と同じく、CoE スターターキットの「Set App Permissions」というアプリを使っても同じ結果となります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/93d1524e-fee1-73c2-fb9e-4a609e9cce3f.png)

以下の通り、所有者が置き換わり、元々の作成者の情報が消えました。つまり、権限がはく奪されました。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/94e7aa05-93f6-8e87-d900-48085e91d3a2.png)

ソリューション外のフローで (上述の方法で所有者変更が出来ないフローで)、どうしても元々の作成者の権限を外したい場合、以下の記事に記載があるような方法で、引継ぎ先の人にフローのコピーを渡して、別のフローとして作成して運用いただく必要があります。

https://qiita.com/kumukai/items/ed7db592cee388e872e1

Power Automate クラウドフローの場合、Power Apps のアプリと違い、利用者の方に URL などを広く共有しているわけではなく、スケジュールで動いている、手動で起動させる、または、Power Apps などでデータ登録をした後に自動で起動し、バックグラウンドで動いているものとなるため、引継ぎ先の人にフローのコピーを渡して、別のフローとして作成、運用いただいたとしても、利用者の方への再周知などは不要と考えます。

個人的に、ソリューション外のフローについては、コピーをもらってインポートでも良いと思っています。この場合、コネクタのアクションごとの接続参照の切り替えは不要になりますし、元の作成者が、異動した後、知らないうちに退職していたとしても心配はないためです。

# Power Apps トリガーのフローの場合

引き継ぐものが、一つのアプリやフローではなく、例えば、アプリ一個とフロー複数のような場合、どちらについても、共同所有者を追加する、所有者を変更するなどの対応をする必要があります。

もちろん、以下のような Power Apps から Power Automate を直接呼び出している場合についても同様です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/986469a1-72ef-29d9-6b1c-7257885ca22e.png)

アプリの共同所有者を追加し、フローについても共同所有者に追加します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/930ff336-159e-52b2-029a-200aafb9652f.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/ee10949e-3df1-32c7-c2c3-3cb5132ff732.png)

私の方でテストした限りでは問題なかったですが、もし、Power Apps を開いた際、Power Automate のフローを上手く読み込めない場合、一度アプリから削除して再度追加してみてください。それでも実行などにおいて問題がある場合は、上述の記事の方法で、引継ぎ先の人の方で Power Autoamte のフローを作成 (実質コピー) し、その上で、Power Apps からそちらのフローを追加してみます。流石に、そこまですれば問題なく動作するはずです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/df372fe6-baf0-48b7-6de3-2d1f223f60dd.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/aed5b7c7-b721-eec4-2c0d-46607f0c1edd.png)

# データソース側のアクセス権を外す

アプリについて、所有権限は残しておいてもいいが、異動する人について、データにはできるだけアクセスさせたくない場合は、以下のような対応をすれば、アプリの編集は出来るものの、実質データにはアクセスできないため、十分なことが出来ないようにすることは可能です。

* Power Apps のアプリは共同管理者を追加する (共同管理者として残したまま)
* Power Automate はコピーして引継ぎ先の人が管理する
* アプリやフローのデータソース側のアクセス権を外す

※Power Automate に共同所有者権限を追加しただけの場合、引継ぎ先の人が、例えば SharePoint リストに対する接続情報を更新した場合、元々の作成者も、引継ぎ先の人の権限を使ってフローに接続することが出来てしまうかもしれないため、コピーして別のフローとした引き継いだ方がいいと思います

SharePoint リストの場合、以下のようにサイトからアクセス権を削除します。SharePoint サイトについて、Teams のチームと紐づいている場合は、Teams のチームから外す、SharePoint サイトに対して、グループ宛にアクセス権が付与されている場合は、グループのメンバーから外せばよいと思います。この辺は、場合によっては、部署異動時に IT の管理者の方で行われる場合もあると思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/eb77c0c1-084c-2472-d1a9-151dbae838f5.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/716be904-473b-129c-4da5-4746724f0005.png)

# まとめ

改めてとなりますが、部署異動の際の Power Apps や Power Automate の引継ぎについて、情報を整理してみました。個人的に、実現手段はあるものの、中には難しいアプローチ、市民開発者の方全員が行うことについて、現実的ではないものもあると思います。

そちらも踏まえて、方針を決めた上で、上記いずれかの方法で引き継いでもらえたらと思います。もちろん、いずれの方法を採用するにせよ、引継ぎ後念のため動作確認はいただければと思います。

部署異動の際の Power Apps や Power Automate の引継ぎをする上で、本記事が少しでも参考になれば幸いです。