Microsoft Dataverse データベースを持つ環境のユーザーは、ユーザー所有のレコードにアクセス権を与えることで、他のユーザーと共同作業を行うことができます。 他のユーザーやチームとレコードを共有したり、他のユーザーやチームにレコードを再割り当てしたりすることができます。
このレコード レベルのコラボレーションを管理し、共有レコードへのユーザーアクセスを提供するために、レコードの共有とその許可はすべて PrincipalObjectAccess (POA) テーブルに格納されます。 ユーザーが所有していないレコードや、セキュリティ ロールで適切な権限を持っていないレコードにアクセスしようとすると、システムは POA テーブルをチェックして、そのユーザーのアクセスを承認します。
POA のソース
次のトピックでは、レコード共有を可能にする POA レコードを作成する設定または使用法について概要を説明します。 過剰な共有や POA ストレージの増加を避けるために、設定を確認し、それに応じて更新する必要があります。
再割り当てされたレコードを元の所有者と共有する
既定では、再割り当てされたレコードを元の所有者と共有するかどうかを設定する は いいえ に設定されています。 これは、レコードの所有権が別のユーザーに再割り当てされたときに、レコードの元の所有者がレコードにアクセスできなくなる場所です。 この設定が はい に設定されている場合 、ユーザーが別のユーザーまたはチームにレコードを割り当てるたびに、POA テーブルにレコードが作成されます。 元の所有者は自動的に 共有先として追加されます。
アクセス チーム
レコード連携にアクセス チームを使用した場合、アクセス チームにユーザーが追加されるたびに、POA テーブルにレコードが作成されます。 アクセス チームには 2 種類あります:
システム管理: これらはテンプレートを介して作成され、フォームに埋め込むことで、ユーザーが簡単にメンバーリストを管理できるようになります。 システムは、共有されたレコードに自動的にアクセスチームを作成します。 たとえば、アカウント #1 には、アカウント #2 とは異なるアクセス チームがあるとします。
手動で追加: システムは、共有されたレコードに自動的にアクセスチームを作成します。
直接共有
- ユーザーが明示的に他のユーザーとレコードを共有すると、POA テーブルにレコードが作成されます。
非直接共有
ユーザーがチームにレコードを共有すると、チームの全メンバーに間接的に共有されます。
間接共有は、カスケード共有関係を持つレコード、または親子関係を持つテーブルでも発生します。 親レコードがユーザーやチームに共有されると、共有先のユーザーやチームは、カスケード接続されたすべての子レコードにアクセスできるようになります。 子レコードにアクセスするこれらの権限は、すべて POA テーブルに作成されます。
テーブル リレーションシップの例
テーブルが他のテーブルとリレーションシップを持つように設定することができます (例: 取引先企業からケース) を使用できます。 規定では、リペアレント オプションのリレーションシップは すべてをカスケード に設定されています。 関連するすべてのサブレコードは、親レコードの所有者に共有されます。
例: ユーザー #1 がアカウント #1 を所有しています。 ユーザー #1 はアカウント #1 をユーザー #2 と共有します。 ユーザー #2 は、アカウント #1 の下にケース #1 を作成します。 すぐに使えるリペアレント オプションでは、ユーザー #1 がケース #1 にアクセスすることができます。 これらのユーザー権限はすべて、POA テーブルに取り込まれます。
ソースの共有
RetrieveAccessOrigin API を使用すると、ユーザーまたはチームの特定のテーブルへのアクセス元を特定することができます。 この API は、リクエストに objectId、logicalName、principalId を必要とし、レスポンスにはテーブルへのアクセス権を取得した場所を記述した文字列が返されます。
POA テーブルの成長管理
- ビジネス ニーズを評価し、必要に応じて再アサインされたレコードを元の所有者と共有するかどうかを設定するをオンにします。 これは、システム全体の設定であることに注意してください。 オンにすると、設定はすべてのレコードに適用されます。
- 共有した別のレコードでユーザーのリストが同じでない場合、共同作業のためにユーザーと共有します。
- 同じユーザーリストで頻繁にレコードを共有する場合や、チームとレコードを共有する場合は、チームをレコードの所有者として使用します。
- 部署の構造が複雑で、共有を頻繁に使用している場合:
- 必要な場所だけを共有します。
- 事業単位数を最小限に抑える。
- ユーザーが適切な部署に配置されていることを確認します。
- 異なるビジネスユニットのユーザーが記録にアクセスできるように、チームで共有します。
- レコードに複数のアクセスチームがアクセスできる場合、たとえば、レコードの読み取りのみが可能な営業担当チームと、読み取りと書き込みのフルアクセスが可能な営業マネージャーチームでは、営業担当と営業マネージャーで異なる役割ベースのフォームを使用することを検討してください。
- アクセス チーム メンバーのライフサイクルを管理します。 コラボレーションに不要になったユーザーを削除します。
- コラボレーションが終了したら、すべてのアクセスメンバーを削除します。
POA レコードの削除
POA テーブルはシステムによって管理され、ユーザーまたはチームがそれぞれのレコードに適切にアクセスできるようになります。 組織に定義されたセキュリティ モデルを壊す可能性があるため、このテーブルでの直接削除はサポートされていません。 POA テーブルをクリーンアップする正しい方法は、セキュリティ モデルを調整し、以前に付与されたアクセス権を取り消すことです。
トラブルシューティング ガイド
テーブル リレーションシップのカスケード構成が リペアレント または シェア から カスケードなし へ変更 になっている場合、この記事を使って継承されたアクセスをクリーンアップします。 これにより、不要な POA レコードが削除されます。 詳細情報は、継承済みアクセスをクリーンアップする方法 を参照してください。
継承済みアクセス権のクリーンアップは、カスケード動作が カスケードなし に変更された後に残存する古い継承済みアクセス権をクリーンアップするシステム ジョブです。 詳細情報: 継承されたアクセス権のクリーンアップ
POA によってユーザー アクセスが許可されたかどうかを確認するには、ユーザーがアクセス権を持っている理由を確認する を参照してください。