はじめに
まず、Power Apps のアプリや Power Automate のフロー等のリソースは、環境という場所に保存されます。
既定 (Default) のみの場合はそれほど意識しないのですが、「個別の環境で Dataverse を利用するキャンバスアプリを作成したので共有したいけどどうすればいいの？」という相談をいただくことがあるため、改めてこの観点で情報を整理して見たいと思います。
Dataverse を利用するキャンバスアプリを利用するために必要なことは
まず、Dataverse を利用するキャンバスアプリを利用するために必要なことは主に以下の 3 つです。
- 環境へのアクセス権がある
- アプリが共有されている
- アプリが利用するテーブルへのアクセス権がある
それぞれについて説明していきます。
環境へのアクセス権がある
上述の通り、アプリやフロー等は、環境に保存されます。テナントに必ず一つ存在する既定の環境の場合、すべてのユーザーが環境へのアクセス権があるためあまり意識しませんが、個別の環境を利用する場合は、こちらについて考慮が必要になります。
Microsoft 365の「テナント」とは、一言で言えば、あなたの会社や組織が Microsoft 365 を利用するための「専用のスペース」です。ある会社が Microsoft 365 を契約すると、その会社専用のテナントが作られ、そのテナントの中で全ての作業が行われます。
以下は、環境を作成する際に、環境へのアクセスをセキュリティグループのメンバーに限定するか制御する箇所になります。こちらの箇所でセキュリティグループを設定している場合は、セキュリティグループのメンバーではない人は環境へのアクセス権がないことになります。
こちらの設定において注意することとしては、こちらでセキュリティグループを指定しなかったとしても、テナント内の全ユーザーがその環境でアプリを作成したり、アプリを実行できたりするという訳ではない点です。これらのことができるようになるためには、後述の要件も満たす必要があります。
逆に言えば、例えば、全社でアプリを利用したい場合、上記箇所でセキュリティグループを指定すると、そのセキュリティグループのメンバーに対してしかアプリを共有できなくなることになります。
以下は、環境へアクセス可能なユーザーをセキュリティグループ (総務部チーム) にした際に、グループに所属していないユーザー (testuser2) にアプリを共有しようとした際にエラーとなってしまった際の画面ショットです。
もちろん、Power Platform 管理センター側で環境にユーザーを追加しようとした際も以下のような結果になり、ユーザーを追加できません。
そのため、最終的にどのユーザーに対してアプリを共有したいかを踏まえ、必要に応じてセキュリティグループを指定する必要があります。
アプリが共有されている
こちらは、Dataverse を利用する、利用しないに関わらず必要な操作です。
しかし、Dataverse を利用するアプリの場合、単にアプリを共有しただけではアプリは正しく動作しません。
以下の箇所にある通り、アプリの利用者はアプリが利用するテーブルへのアクセス権が必要になります。
アプリが利用するテーブルへのアクセス権がある
上述の通りアプリを共有したとしても、アプリは正しく動作しません。そのため、アプリの利用者に対して、アプリが利用するテーブルへのアクセス権を付与する必要があるのですが、Dataverse の場合、セキュリティロールというものを介してテーブルへのアクセス権を付与します。
セキュリティロールについては、以下の記事がとてもわかり易いので参考にしてください。
セキュリティロールを介してテーブルへのアクセス権が付与されることで、最終的にアプリが利用できるようになります。
セキュリティロールについて、アプリを利用するために (アプリで利用するテーブルのアクセス権を付与するために)、そのアプリ専用のセキュリティロールを作成することで、アプリ利用者に必要最低限のアクセス権を付与することが可能になります。
例えば、以下は、Basic User というテンプレートとなる事前定義済みのセキュリティロールをコピーして、勤務状況をシェアするアプリで使用するテーブルに対してアクセス権を付与している例です。このようにすることで、このセキュリティロールを付与されたユーザーは、その環境内のそれ以外のアプリで利用するテーブルは操作できないことになります。
特権 (作成、読み取りなど) についても上記記事が参考になりますが、端的に言うと、ユーザーは、自分が所有 (基本的にデータを登録すると自分がそのレコードの所有者になります) しているレコード (行) のみ操作可能、組織は、誰が作成した行であってもその操作が可能という意味になります。
そのため、例えば、自分が作成した行について、アプリを利用する人は誰でも読み取り可能ですが、変更や削除は自分 (アプリの管理者は除く) しかできないようにしたい場合は、読み取りを組織にして、それ以外はユーザーにするみたいな感じで設定します。
"なし"はその操作ができない、"部署"、"部署配下"は Dataverse 特有の仕組みであり、複雑であることや、市民開発では利用しないケースも多いため、こちらの記事での説明は割愛いたします。
Power Platform の環境に対する操作をするためのセキュリティロールも存在します。例えば、環境自体を管理するシステム管理者、その環境内でアプリやフローなどのリソースの作成が可能になる環境作成者 (環境自体が作成できるわけではないです) などの事前定義済みセキュリティロールがございます。こちらについても上述の記事で紹介されております。
そのため、アプリを共有されて利用するだけ (アプリを利用するためのセキュリティロールを付与されただけ) のユーザーは、そのアプリを利用することはできますが、環境作成者のセキュリティロールは付与されていないため、その環境でアプリやフローを新規に作成することはできないことになります。このようにすることで、環境において、アプリを利用するだけのユーザーとアプリやフローを作成することができるユーザーを分離することが可能です。
最後に、セキュリティロールの割当について、ユーザーに対して割り当てる方法、グループに対して割り当てる方法を説明します。
ユーザーに対して割り当てる
ユーザーに対してセキュリティロールを割り当てる方法は２つあります。１つ目は、以下のようにアプリを共有する際に合わせてユーザーにセキュリティロールを付与します。
また、Power Paltform 管理センター側でも以下のようにして割り当てる事が可能です。
グループに対して割り当てる
多くの人に共有するアプリの場合、ユーザー一人一人にセキュリティロールを付与するのは現実的ではありません。そのため、グループに対して割り当てると非常に楽です。
幸い、Microsoft 365 を利用している場合、既に、部署や Teams のチームに紐づくグループ (Microsoft 365 グループ) が作成されており、特に前者の場合、組織の変更があった際も正確にメンテナンスも行われていることが多いため、アプリ作成者の方からすると、このようなグループを利用するのが一番楽だと思います。
こちらについても、ユーザーと同じように、アプリを共有する際にグループを検索して選択してセキュリティロールを割り当てることが可能です。
Power Platform 管理センターからも割当可能です。こちら、チームの作成画面にて、以下いずれかのグループを選び、チームに対してセキュリティロールを割り当てます。
AAD Office グループは、Microsoft 365 グループ (Teams のチーム作成時にも作成されます) を意味します。
アプリの共有画面では直接グループを指定してセキュリティロールの割当ができるのに、Power Platform 管理センターではチームを介さないとグループにセキュリティロールを割り当てられないの？と不思議に感じたかもしれません。
こちらについて、実は、アプリの共有画面でグループに対してセキュリティロールを割り当てた場合、裏でチームが作成されてセキュリティロールが割当たっております。
そのため、いずれの場合においても、以下のように、セキュリティグループや Microsoft 365 グループ (Teams のチーム作成時にも作成されます) に対してセキュリティロールを割り当てる場合、チームを介して割り当てていることになります。そのため、いずれかの方法でグループに対してセキュリティロールを割り当てていただければと思います。
まとめ
今回は、Dataverse 環境でキャンバスアプリを共有する方法について紹介しました。環境、セキュリティロール、テーブルへのアクセス権付与、チームなど、Dataverse のない環境では意識しなかった概念、用語も沢山あり、混乱してしまう、理解に時間を要す場合もあると思うので、こちらの記事が理解促進に少しでもつながれば幸いです。