设置层次结构安全性以对数据进行精细访问

备注

如果您已启用仅统一接口模式，则在使用本文中的过程之前，请执行以下操作：

1. 在导航栏上选择设置 ()。
2. 选择高级设置。

   

层次结构安全模型是现有使用业务部门、安全角色、共享和团队的 Dynamics 365 Customer Engagement (on-premises) 安全模型的扩展。 它可以与任何其他现有的安全模型结合使用。 层次结构安全性提供对组织记录更细粒度的访问，并帮助减少维护成本。 例如，在复杂方案中，则可以先创建多个业务部门，然后添加层次结构安全性。 这会实现对数据的更细粒度的访问，并极大地减少大量业务部门所需的维护成本。

管理层次结构和职位层次结构安全模型

两种安全模型均可用于层次结构、管理层次结构和职位层次结构。 在管理层次结构中，经理必须与下属处于同一业务部门，或处于下属业务部门的父业务部门之中，才能访问下属的数据。 职位层次结构允许数据跨业务部门进行访问。 如果您的组织是一个财务组织，则可能更希望使用管理层次结构模型，以防止经理访问其业务部门之外的数据。 但是，如果贵公司是客户服务组织中的一部分，并希望经理访问不同业务部门处理的服务案例，那么职位层次结构可能会更加适合您。

备注

当层次结构安全模型提供对数据的特定级别访问时，使用其他安全窗体，如安全角色，则可以获取附加访问。

管理层次结构

管理层次结构安全模型基于管理链或直接下属结构，通过使用系统用户实体上的“经理”字段来构建经理和下属的关系。 利用此安全模型，经理可以访问其下属有权访问的数据。 经理可以代表其直接下属执行工作，或访问需要审批的信息。

备注

利用管理层次结构安全模型，经理可以访问属于该用户或该用户所属团队的记录，并访问直接与该用户或与该用户所属团队共享的记录。 当记录被管理链外的用户共享到具有只读访问权限的直接下属用户时，直接下属的经理将具有共享记录的只读访问权限。

除了管理层次结构安全模型外，经理必须对实体至少具有用户级的读取权限，以便查看报表数据。 例如，如果管理器不具有对案例实体的读取访问权限，则管理器无法查看其报表有权访问的案例。

对于经理的同一个管理链中的非直接下属，经理具有非直接下属的数据的只读访问权限。 对于直接下属，经理具有对下属数据的读取、写入、更新、追加以及追加到访问权限。 为了阐明管理层次结构安全模型，让我们看一下下面的关系图。 CEO 可以读取或更新销售数据的 VP 和服务数据的 VP。 但是 CEO 只能读取销售经理数据和服务经理数据，以及销售和支持数据。 您可以通过“深度”进一步限制经理可访问的数据量。 深度用于限制经理对其下属数据的只读访问权限的深度级别。 例如，如果深度设置为 2，则 CEO 可以查看销售 VP、服务 VP、销售及服务经理的数据。 但是 CEO 无法查看销售数据或支持数据。

请务必注意，如果直接下属对实体的安全访问权限比其经理更高，经理可能无法看到直接下属有权访问的所有记录。 以下示例介绍了这个情况。

• 一业务部门有三个用户：用户 1、用户 2 和用户 3。

• 用户 2 是用户 1 的直接下属。

• 用户 1 和用户 3 对客户实体具有用户级别的读取访问权限。 具有此访问级别的用户可以访问其负责的用户记录、与该用户共享的记录以及与该用户所属团队共享的对象。

• 用户 2 对客户实体具有业务部门读取访问权限。 这允许用户 2 查看该业务部门的所有客户，包括用户 1 和用户 3 负责的所有客户。

• 用户 1 作为用户 2 的直接经理，有权访问用户 2 负责或与用户 2 共享的客户，以及与用户 2 所属团队共享或由该团队负责的客户。 但是，用户 1 无法访问用户 3 的客户，尽管其直接下属可以访问用户 3 的客户。

职位层次结构

职位层次结构并不基于诸如管理层次结构的直接下属结构。 用户不必是访问用户数据的其他用户的实际经理。 作为管理员，要定义组织中的各种工作职位，并在职位层次结构中对其进行排列。 然后，您将用户添加到任何给定职位，或者换句话说，使用特定职位“标记”用户。 在给定的层次结构中，一个用户只能用一个职位进行标记，但是多个用户可使用同一职位。 在层次结构中处于更高职位的用户有权访问直接上级路径中处于较低职位的用户数据。 直接更高职位中的用户对直接上级路径中较低职位的数据具有读取、写入、更新、附加以及附加到访问权限。 非直接更高职位对直接上级路径中较低职位的数据具有只读访问权限。

为了阐明直接上级路径的概念，让我们看一下下面的关系图。 销售经理职位有权访问销售数据，但是，它无权访问位于不同上级路径中的支持数据。 对于服务经理职位也是一样。 服务经理职位无权访问位于销售路径中的销售数据。 与在管理层次结构中一样，您可以使用“深度”限制更高职位可访问的数据量。 深度将会限制更高职位对直接上级路径中较低职位的数据所具有的只读访问权限的深度级别。 例如，如果深度设置为 3，CEO 职位可以查看从销售 VP 与服务职位 VP 一直到销售与支持职位的所有数据。

备注

利用职位层次结构安全性，处于较高职位的用户可以访问属于较低职位用户或该用户所属团队的记录，并访问直接与该用户或与该用户所属团队共享的记录。

除了职位层次结构安全模型外，更高级别的用户必须至少拥有对实体的用户级别的读取特权，以便查看较低职位的用户有权访问的记录。 例如，如果处于较高级别的用户没有对案例实体的读取访问权限，则该用户将无法查看较低位置用户有权访问的案例。

设置层次结构安全性

若要设置安全层次结构，您必须具有管理员安全角色。

默认情况下，禁用层次结构安全性。 若要启用：

1. 转到设置>安全。

2. 选择层次结构安全性并选择启用层次结构建模。

重要提示

若要在层次结构安全性中做出更改，您必须具有更改层次结构安全设置特权。

在启用层次结构建模后，通过选择管理层次结构或自定义职位层次结构来选择特定模型。 为现成的结构层次安全性启用所有系统实体，但可以从结构层次中排除选择性实体。 下面显示的层次结构安全性窗口：

将深度设置为所需值，以限制经理对其下属数据所拥有的只读访问权限的深度级别。 例如，如果深度为 2，经理仅具有访问其自己帐户和下属帐户两个级别的权限。 在我们的示例，如果以销售 VP 身份登录 Customer Engagement 应用，而不以能查看所有帐户的管理员身份登录，则只能查看在红色矩形中显示的活动用户帐户，如下所示：

备注

当层次结构安全性授予销售 VP 访问红色矩形中记录的权限时，基于销售 VP 拥有的安全角色，还可以授予其他访问权限。

设置管理和职位层次结构

通过使用系统用户记录上的经理关系，轻松创建管理层次结构。 请使用经理 (ParentsystemuserID) 查找字段来指定用户的经理。 如果已经创建了职位层次结构，则还可以在职位层次结构中用特定职位标记用户。 在以下示例中，销售员向管理器层次结构中的销售经理汇报报表，并还在位置层次结构中具有销售位置：

若要将用户添加到职位层次结构中的特定职位，请在用户记录窗体上使用名为“职位”的查找字段，如下所示：

重要提示

若要将用户添加到职位或更改用户职位，则必须具有分派用户职位的权限。

若要更改用户记录窗体上的职位，请在工具栏上，选择更多(…)，然后选择其他职位，如下所示：

若要创建职位层次结构：

1. 转到设置>安全。

2. 选择位置。

   对于每个职位，请提供该职位的名称，该职位的父级和说明。 通过使用查找字段调用职位中的用户来将用户添加到此职位。 以下是带有可用位置的位置层次结构示例。

   

   启用用户及其相应职位的示例，如下所示：

   

性能注意事项

若要提高性能，建议：

• 在管理/职位下对 50 个或更少用户保持有效的层次结构安全性。 在管理/职位下，您的层次结构可能具有 50 多个用户，但是，您可以使用深度设置以减少具有只读访问权限级别的数量，并通过此设置将管理/职位下的用户的有效数量限制为不超过 50 个用户。

• 将层次结构安全模型与其他现有安全模型结合使用，用于更复杂的方案。 避免创建大量的业务部门，改为创建较少的业务部门并添加层次结构安全性。

另请参阅

Microsoft Dynamics 365 for Customer Engagement 的安全概念
查询及可视化分层数据