次の方法で共有


テーブルのアクセス許可を使用したセキュリティの構成

注意

2022 年 10 月 12 日より、Power Apps ポータルは Power Pages となります。 詳細: Microsoft Power Pages の一般提供が開始されました (ブログ)
Power Apps ポータルのドキュメントは、近日中に Power Pages ドキュメントに移行、統合されます。

個々のレコードに適用されるポータルのセキュリティを適用するには、テーブルのアクセス許可を使用します。 Web ロールにテーブルのアクセス許可を追加することで、レコードの所有権やアクセスの権限や概念に論理的に対応する組織内のロールを定義することができます。 1 人の取引先担当者は任意の数のロールに属することができ、指定されたロールには任意の数のテーブルのアクセス許可を含めることができます。 詳細情報: ポータルの Web ロールの作成

ポータル サイト マップ内の URL を変更したり、それらにアクセスするためのアクセス許可は、コンテンツ認証を通じて付与されますが、サイト マネージャーは、基本フォームと基本リストを使用して作成されたカスタム Web アプリケーションを保護する必要もあります。 詳細情報: 基本フォームの定義 および リストの定義

これらの機能を確保するにあたり、テーブルのアクセス許可では詳細な権限を付与することができ、リレーションシップ定義によってレコード レベルのセキュリティを有効にすることができます。

テーブルのアクセス許可を Web ロールに追加

  1. ポータル管理アプリを開きます。

  2. ポータル>Web ロールにアクセスし、アクセス許可を追加する Web ロールを開きます。

  3. 関連で、テーブルのアクセス許可を選択します。

  4. 既存テーブルのアクセス許可の追加を選択して、Web ロールに既存のテーブルのアクセス許可を追加します。

  5. テーブルのアクセス許可を参照するか、新しいテーブルのアクセス許可 を選択して、新しいテーブルのアクセス許可レコードを作成します。

    テーブルのアクセス許可を Web ロールに追加する。

新しいテーブルのアクセス許可レコードを作成するときは、最初の手順として、セキュリティで保護されるテーブルを決定します。 次のステップは、次のセクションで説明するように、アクセスの種類を定義し、—グローバル以外のアクセスの種類である場合—そのアクセスの種類を定義する関連付けを定義します。 最後に、そのアクセス許可を通じてロールに付与される権限を決定します。 権限は累積されるため、読み取り権限を持つロールと、読み取りと更新権限を持つロールに分かれているユーザーは、2 つのロールの間で重複するレコードの読み取りと更新権限を持つことになります。

注意

Web ページ、Web ファイル、その他の構成テーブルなどのテーブルの選択は無効であり、他の意図しない結果を招く可能性があります。 ポータルでは、テーブルのアクセス許可ではなく、コンテンツ アクセス コントロールに基づいてコンフィギュレーション テーブルのセキュリティがアサートされます。

グローバル アクセスの種類

アクセス タイプにグローバルを持つロールに読み取り権限を持つテーブル許可レコードが付与されている場合、そのロールの担当者は定義されたテーブルのすべてのレコードにアクセスできます。 たとえば、彼らはすべての潜在顧客、すべての取引先企業などを表示できます。 このアクセス許可は、すべてのリストに自動的に反映され、特にそのリストで定義された Microsoft Dataverse ビューに対してすべてのレコードを表示します。 さらに、ユーザーがアクセス権を持たない基本フォームを通じてレコードにアクセスしようとすると、アクセス許可エラーが発生します。 たとえば、自動車販売店で認証されたユーザー全員にすべての車のリストを表示するサンプル シナリオを参照してください。

取引先担当者アクセスの種類

取引先担当者アクセスの種類によって、アクセス許可レコードが定義されているロールにサインインしているユーザーは、定義された関連付けによって、そのユーザーの取引先担当者レコードに関連するレコードに対してのみアクセス許可が付与されます。

一覧では、このアクセスの種類は、現在のユーザーに直接リンクされるレコードのみを取得するリストによって表示されるどの Microsoft Dataverse ビューにも、フィルターが追加されていることを意味します。 (シナリオによっては、この関係を所有権や管理権と見なすこともできます)。たとえば、自動車販売店で所有する車のリストを表示、更新、削除する シナリオの例を参照してください。

基本フォームでは、レコードの読み込み時にその関連付けが存在している場合にのみ、読み取り、作成、書き込みなどの適切なアクセス許可が付与されます。 詳細 : 基本フォームを定義する を参照してください。

取引先企業アクセスの種類

取引先企業アクセスの種類では、アクセス許可レコードが定義されているロールにサインインしているユーザーは、定義された関連付けを通じてそのユーザーの取引先企業の親会社レコードに関連付けられたレコードに対してのみ、アクセス許可で付与される権限を持つことになります。

このアクセスタイプでは、ユーザーの取引先企業の親会社に関連付けられている、選択したテーブルのレコードのみがリストに表示されます。 たとえば、あるテーブル権限で、取引先企業のアクセスタイプを持つリード テーブルへの読み取りアクセスを許可した場合、この権限を持つユーザーは、そのユーザーの取引先企業の親会社のみのすべてのリードを表示できます。 たとえば、スタッフが自社が所有する、すべての自動車販売店を表示できるようにするサンプル シナリオを見てみましょう。

セルフ アクセスの種類

セルフ アクセスのタイプを使用すると、ユーザーが自分の取引先担当者 (ID) レコードに対して持つ権利を定義できます。 ユーザーは基本フォームまたはマルチステップ フォームを使用して自分のプロファイルにリンクされている連絡先レコードを変更することができます。 既定のプロフィール ページには特別なフォームが組み込まれており、ユーザーは基本的な連絡先情報を変更したり、マーケティング リストへの登録や削除を行うことができます。 このフォームがご利用のポータルに含まれている場合 (既定では含まれています)、ユーザーがこれを使用するためのアクセス許可は不要です。 ただし、ユーザー取引先担当者レコードを対象とするカスタム基本フォームやマルチステップ フォームを使用する場合は、このアクセス許可が必要です。 たとえば、自動車販売店のスタッフが自身のプロフィール ページで連絡先を更新できるようにするシナリオのサンプルをご覧ください。

親アクセスの種類

最も複雑なケースでは、既にテーブルのアクセス許可レコードが定義されているテーブルから、リレーションシップを持たないテーブルに対してアクセス許可が付与されます。 このアクセス許可は、実際には親テーブルのアクセス許可の子レコードです。

親アクセス許可レコードでは、特定のテーブルに対するアクセス許可とアクセスの種類が定義されます (多くの場合は、グローバルまたは取引先担当者のアクセスの種類ですが、親スコープも可能です)。 そのテーブルは、取引先担当者 (取引先担当者のアクセスの種類がある場合) に関連付けられている場合と、グローバルに定義されている場合があります。 このアクセス許可が設定されている場合は、親の関連付けで定義されたテーブルと他のテーブルとの関連付けを定義する、子アクセス許可が作成されます。

親テーブルのアクセス許可で定義されたレコードへのアクセス権を持つ Web ロールのユーザーは、親レコードに関連するレコードに対しても、子のアクセス許可で定義された権限が与えられます。

属性とリレーションシップ

次の表は、テーブルのアクセス許可の属性について説明したものです。

件名 内容
件名 レコードの内容を示す名前。 これは必須フィールドです。
テーブル名 セキュリティで保護されるテーブル、子アクセス許可の関連テーブルをセキュリティ保護するために取引先担当者の関連付けまたは親の関連付けを定義するテーブルの論理名。 これは必須フィールドです。
アクセスの種類 (必須)
  • グローバル: 所有者 (取引先担当者) の要件なしに、テーブル レコードに権限を付与します。
  • 取引先担当者: オーナー (取引先担当者) と直接関係のあるテーブル レコードに権限を付与します。
  • アカウント: アカウントが取引先担当者の所属取引先企業/上司であると仮定して、所有者として機能するアカウントとの関連付けを持つテーブル レコードに権限を付与します。
  • : 親のアクセス許可関連付けの連鎖を通じて、テーブル レコードに特権を付与します。
アクセスの種類の関連付け 選択したアクセスの種類によって異なります。
  • 取引先担当者の関連付け: アクセスの種類 = 取引先担当者の場合にのみ必要です。
    取引先担当者と、テーブル名フィールドで指定されたテーブル間の関係のスキーマ名です。
  • 取引先企業の関連付け: アクセスの種類 = 取引先企業の場合にのみ必要です。
    取引先企業と、テーブル名フィールドで指定されたテーブル間の関係のスキーマ名です。
  • 親の関連付け: 親テーブルのアクセス許可が割り当てられている場合にのみ必要です。
    テーブル名フィールドで指定されたテーブルと、親テーブルのアクセス許可レコードのテーブル名フィールドで指定されたテーブル間の関連付けスキーマ名です。
    • 親テーブルのアクセス許可: アクセスの種類 = 親の場合にのみ必要です。

注意: 選択したテーブルとの既存のリレーションシップがない場合、利用可能なリレーションシップは空になります。 テーブルの関連付けを作成するには、テーブルの関連付けの概要を参照してください。
既読 ユーザーがレコードを読み取ることができるかどうかを制御する特権。
書き込み ユーザーがレコードを更新できるかどうかを制御する特権。
作成 ユーザーが新しいレコードを作成できるかどうかを制御する特権。 特定のテーブルの種類に対してレコードを作成する権限は、個々のレコードに適用されるのではなく、テーブルのクラスに適用されます。
Delete キー ユーザーがレコードを削除できるかどうかを制御する特権。
追加 ユーザーが指定されたレコードに別のレコードを添付できるかどうかをコントロールする特権です。 追加アクセス権と追加先アクセス権は連係して機能します。 レコードを別のレコードに関連付けるには、そのユーザーがこれら両方の権限を持っている必要があります。 たとえば、ケースにメモを関連付ける場合は、メモに対する "追加" アクセス権と、その操作対象のケースに対する "追加先" アクセス権が必要です。
追加先 ユーザーが当該レコードを別のレコードに追加できるかどうかをコントロールする特権です。 アペンドとアペンド先のアクセス権は、上述のように組み合わせて機能します。

リードに関連するタスクのグローバル アクセス許可

ここでは、一覧および基本フォームを使用して、ポータル上のすべての潜在顧客を、カスタムの潜在顧客マネージャー Web ロールのユーザーに表示する場合について考えてみましょう。 リード編集フォーム (リストでリードの行が選択されたときに起動されます) では、関連するタスク レコードがサブグリッドに表示されます。 これらのレコードに、リード マネージャー ロールのすべてのユーザーがアクセスできるようにする必要があるとします。 その場合、最初の手順としてリード マネージャー ロールのすべてのユーザーに対して、グローバル アクセス許可を付与します。

このロールには、グローバル アクセスの種類を持つ潜在顧客テーブルの関連テーブルのアクセス許可があります。

このロールのユーザーは、ポータル上の一覧またはフォームを通じて、すべての潜在顧客にアクセスできます。

リードにグローバルのアクセス許可を付与する。

続いて、グローバル リード アクセス許可に子アクセス許可を追加します。 親の許可レコードを開いた状態で、子テーブルのアクセス許可サブグリッドにアクセスし、新しいテーブルのアクセス許可を選択して新しいレコードを追加します。

グローバル リード アクセス許可に子のアクセス許可を追加する。

テーブルとしてタスクを、アクセスの種類として保護者を選択します。 親の関連付け (リード_タスク) が選択できることに留意してください。 このアクセス許可は、親アクセス許可を持つ Web ロールの担当者が、リードに関連するすべてのタスクに対するグローバル権限を持つことを意味します。

リストがこれらのアクセス許可を尊重するには:

  • 一覧のテーブルのアクセス許可を有効にする必要があります。

    一覧のテーブルのアクセス許可を有効にする。

  • ユーザーが、アクセス許可が付与されているアクションを実際に実行できるようにするアクションが必要です。

    アクセス許可が付与されているアクション。

  • 基本フォーム レコードでもアクセス許可を有効にする必要があります。

    基本フォーム レコードで有効なアクセス許可。

  • フォームは、子権限で有効にするテーブルのサブグリッドを含むページを表示している必要があります。 この場合、テーブルはタスクになります。

    テーブルのあるサブグリッド - タスク。

タスクの読み取り権限や作成権限を有効にする場合は、それらの基本フォームも構成し、 [関連] 検索フィールドを削除するようにフォームを編集する必要があります。

これにより、リードに関連するすべてのタスクに対するアクセス許可が付与されます。 タスクがリストに表示されている場合、リストにフィルターが追加され、リードに関連するタスクだけがリストに表示されるようになります。 この例では、基本フォーム上のサブグリッドにそれらが表示されます。

タスクの例。

タスクの取引先担当者アクセス タイプのアクセス許可

もう 1 つの例として、タスクへのアクセスを許可する際、取引先担当者がそのタスクの親リードに関連付けられている場合について考えてみましょう。 このシナリオは、前述のセクションの例とほぼ同じではありますが、この場合、親アクセス許可のアクセス タイプが「グローバル」ではなく「コンタクト」である点が異なります。 関連付けは、潜在顧客テーブルと取引先担当者テーブル間の親の関連付けで指定する必要があります。

これらのアクセス許可が設定されると、リード マネージャー ロールのユーザーは、"アクセス タイプ: 取引先担当者"の権限で指定された自分に直接関連するリードにアクセスでき、子アクセス許可で指定された同じリードに関連するタスクにアクセスできます。

関連項目

ポータルの Web ロールの作成
ポータル用 Web ページへのアクセスの制御

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。