) を選択します。
階層セキュリティ モデルは、ビジネス ユニット、セキュリティ ロール、共有、チームを使用する既存の Dynamics 365 Customer Engagement (オンプレミス) セキュリティ モデルの拡張機能です。 他のすべての既存のセキュリティ モデルと組み合わせて使用できます。 階層セキュリティは、組織のレコードへのより細かいアクセスを提供し、メンテナンス コストを削減するのに役立ちます。 たとえば、複雑なシナリオでは、まず複数の部署を作成してから、階層のセキュリティを追加できます。 これにより、多数のビジネス ユニットが必要とする可能性があるメンテナンス コストがはるかに少なく、データへのより細かいアクセスが実現されます。
マネージャー階層と位置階層のセキュリティ モデル
階層には、Manager 階層と Position 階層の 2 つのセキュリティ モデルを使用できます。 マネージャー階層では、レポートのデータにアクセスするには、マネージャーがレポートと同じ部署内にあるか、レポートの部署の親部署内にある必要があります。 Position 階層を使用すると、ビジネス ユニット間でデータ にアクセスできます。 財務組織の場合は、マネージャーの階層モデルを使用して、マネージャーが部署外のデータにアクセスするのを防ぐことができます。 ただし、顧客サービス組織の一部であり、マネージャーが異なる部署で処理されるサービス ケースにアクセスできるようにする場合は、Position 階層が適切に機能する可能性があります。
注
階層セキュリティ モデルはデータへの一定レベルのアクセスを提供しますが、セキュリティ ロールなど、他の形式のセキュリティを使用して追加のアクセスを取得できます。
マネージャー階層
マネージャー階層のセキュリティ モデルは、管理チェーンまたは直接レポート構造に基づいており、管理者とレポートの関係は、システム ユーザー エンティティの [マネージャー] フィールドを使用して確立されます。 このセキュリティ モデルを使用すると、マネージャーはレポートがアクセスできるデータにアクセスできます。 直属の部下に代わって作業を実行したり、承認が必要な情報にアクセスしたりできます。
注
マネージャー階層セキュリティ モデルを使用すると、マネージャーは、ユーザーまたはユーザーがメンバーであるチームが所有するレコードと、ユーザーまたはユーザーがメンバーであるチームと直接共有されるレコードにアクセスできます。 管理チェーンの外部にあるユーザーが、読み取り専用アクセス権を持つ直接レポート ユーザーにレコードを共有する場合、直接レポートのマネージャーは共有レコードへの読み取り専用アクセス権のみを持っています。
マネージャー階層のセキュリティ モデルに加えて、レポートのデータを表示するには、少なくともユーザー レベルのエンティティに対する読み取り特権がマネージャーに必要です。 たとえば、マネージャーが Case エンティティへの読み取りアクセス権を持っていない場合、マネージャーはレポートがアクセスできるケースを表示できません。
マネージャーの同じ管理チェーン内の非直属のレポートの場合、マネージャーは直接レポート以外のデータに対する読み取り専用アクセス権を持っています。 直接レポートの場合、マネージャーはレポートのデータに対する読み取り、書き込み、更新、追加、AppendTo アクセス権を持っています。 マネージャー階層セキュリティ モデルを示すために、次の図を見てみましょう。 CEO は、Sales データの VP とサービス データの VP を読み取りまたは更新できます。 ただし、CEO が読み取ることができるのは、Sales Manager データと Service Manager データ、および Sales と Support のデータのみです。 "Depth" を使用してマネージャーがアクセスできるデータの量をさらに制限できます。 Depth は、マネージャーがレポートのデータに対する読み取り専用アクセス権を持つ深いレベルの数を制限するために使用されます。 たとえば、深度が 2 に設定されている場合、CEO は、営業担当副社長、サービス担当副社長、およびサービス マネージャーのデータを確認できます。 ただし、CEO には Sales データやサポート データは表示されません。
直属のレポートが上司よりもエンティティに対するより深いセキュリティ アクセス権を持っている場合、マネージャーは直属のレポートがアクセスできるすべてのレコードを表示できない可能性があることに注意してください。 この点を次の例に示します。
1 つの部署には、ユーザー 1、ユーザー 2、ユーザー 3 の 3 人のユーザーがあります。
ユーザー 2 は、ユーザー 1 の直属のレポートです。
ユーザー 1 とユーザー 3 には、アカウント エンティティに対するユーザー レベルの読み取りアクセス権があります。 このアクセス レベルにより、ユーザーは自分が所有するレコード、ユーザーと共有されるレコード、およびユーザーがメンバーであるチームと共有されるレコードにアクセスできます。
ユーザー 2 には、取引先企業エンティティに対する部署の読み取りアクセス権があります。 これにより、ユーザー 2 は、ユーザー 1 とユーザー 3 が所有するすべてのアカウントを含む、部署のすべてのアカウントを表示できます。
ユーザー 1 は、ユーザー 2 の直接管理者として、ユーザー 2 が所有または共有しているアカウント、およびユーザー 2 がメンバーであるチームと共有または所有しているアカウントにアクセスできます。 ただし、直接レポートがユーザー 3 アカウントにアクセスできる場合でも、ユーザー 1 はユーザー 3 のアカウントにアクセスできません。
位置階層
Position 階層は、マネージャー階層のような直接レポート構造に基づいていません。 ユーザーのデータにアクセスするために、ユーザーが別のユーザーの実際のマネージャーである必要はありません。 管理者は、組織内のさまざまな職務を定義し、Position 階層に配置します。 次に、特定の位置にユーザーを追加するか、または言うとおり、特定の位置を持つユーザーに "タグ付け" します。 ユーザーには、特定の階層内の 1 つの位置でのみタグ付けできますが、1 つの位置を複数のユーザーに使用できます。 階層内の上位のユーザーは、直接の先祖パスの下位のユーザーのデータにアクセスできます。 直接上位の位置には、直接の先祖パス内の下位の位置のデータに対する読み取り、書き込み、更新、追加、AppendTo アクセスがあります。 非直接上位の位置には、直接の先祖パス内の下位位置のデータへの読み取り専用アクセス権があります。
直接先祖パスの概念を説明するために、次の図を見てみましょう。 Sales Manager の役職は Sales データにアクセスできますが、サポート データにはアクセスできません。これは異なる先祖パスにあります。 Service Manager の位置についても同様です。 Sales パスにある Sales データにアクセスすることはできません。 マネージャー階層と同様に、"Depth" を使用して上位の位置からアクセスできるデータの量を制限できます。 深さは、上位の位置に読み取り専用アクセス権を持つ深いレベルの数を、直接の先祖パス内の下位の位置のデータに制限します。 たとえば、深度が 3 に設定されている場合、CEO のポジションは、Sales および VP of Service のポジションから Sales および Support のポジションまで、データを見ることができます。
注
位置階層セキュリティを使用すると、上位のユーザーは、下位のユーザーまたはユーザーがメンバーであるチームが所有するレコード、およびユーザーまたはユーザーがメンバーであるチームに直接共有されるレコードにアクセスできます。
位置階層セキュリティ モデルに加えて、下位のユーザーがアクセスできるレコードを表示するには、上位レベルのユーザーにエンティティに対する少なくともユーザー レベルの読み取り特権が必要です。 たとえば、上位レベルのユーザーが Case エンティティへの読み取りアクセス権を持っていない場合、そのユーザーは下位のユーザーがアクセスできるケースを表示できません。
階層のセキュリティを設定する
セキュリティ階層を設定するには、管理者セキュリティ ロールが必要です。
階層セキュリティは既定で無効になっています。 有効にするには:
[設定]>[セキュリティ]に移動します。
[ 階層セキュリティ ] を選択し、[ 階層モデリングを有効にする] を選択します。
Important
階層のセキュリティを変更するには、階層セキュリティ設定の変更権限が必要です。
階層モデリングを有効にしたら、[ マネージャ階層 ]または[ カスタムポジション階層]を選択して特定のモデルを選択します。 すべてのシステム エンティティは、すぐに使用できる階層セキュリティに対して有効になっていますが、階層から選択的エンティティを除外できます。 次に示す [階層のセキュリティ ] ウィンドウ:
する
Depth を目的の値に設定して、マネージャーがレポートのデータに対する読み取り専用アクセス権を持つレベルの深さを制限します。 たとえば、深さが 2 の場合、マネージャーは自分のアカウントとレポートのアカウントに 2 レベルしかアクセスできません。 この例では、管理者としてではなく、すべてのアカウントを表示できる Customer Engagement アプリにログインした場合、次に示すように、Sales の VP として、赤い四角形に示されているユーザーのアクティブなアカウントのみを表示できます。
注
階層セキュリティでは、Sales の VP に赤い四角形内のレコードへのアクセス権が付与されますが、Sales の VP が持っているセキュリティ ロールに基づいて追加のアクセスを使用できます。
マネージャー階層とポジション階層を設定する
Manager 階層は、システム ユーザー レコードのマネージャー関係を使用して簡単に作成できます。 [マネージャー] (ParentsystemuserID) ルックアップ フィールドを使用して、ユーザーのマネージャーを指定します。 Position 階層を既に作成している場合は、Position 階層の特定の位置でユーザーにタグを付けることもできます。 次の例では、営業担当者はマネージャー階層の営業マネージャーに報告し、また、ポジション階層の販売ポジションも持っています。
位置階層の特定の位置にユーザーを追加するには、次に示すように、ユーザー レコードのフォームの Position という名前のルックアップ フィールドを使用します。
Important
ユーザーを位置に追加したり、ユーザーの位置を変更したりするには、ユーザー権限の 割り当て位置が 必要です。
する
ユーザー レコードのフォーム上の位置を変更するには、ナビゲーション バーで [ その他 ] (...) を選択し、次に示すように別の位置を選択します。
する
Position 階層を作成するには:
[設定]>[セキュリティ]に移動します。
[位置] を選択します。
各位置について、位置の名前、位置の親、および説明を指定します。 この位置のユーザーと呼ばれるルックアップ フィールドを使用して、 この位置にユーザーを追加します。 アクティブな位置を持つ Position 階層の例を次に示します。
対応する位置を持つ有効なユーザーの例を次に示します。
パフォーマンスに関する考慮事項
パフォーマンスを向上させるには、次のことをお勧めします。
効果的な階層のセキュリティは、マネージャー/役職の下で 50 人以下のユーザーに保持します。 階層にはマネージャー/役職の下に 50 人を超えるユーザーが含まれる場合がありますが、Depth 設定を使用すると、読み取り専用アクセスのレベル数を減らすことができます。これにより、マネージャー/役職に基づく有効なユーザー数は 50 ユーザー以下に制限されます。
より複雑なシナリオでは、階層セキュリティ モデルを他の既存のセキュリティ モデルと組み合わせて使用します。 多数の事業単位を作成することは避けてください。代わりに、作成する部署が少なく、階層のセキュリティが強化されます。
こちらも参照ください
Microsoft Dynamics 365 for Customer Engagement のセキュリティの概念
階層データのクエリと視覚化