使用业务部门控制对 Customer Insights - Journeys 记录的访问
业务部门是模型驱动应用的一项标准功能，或链接的业务操作（Dynamics 365 Sales、Dynamics 365 Customer Service、Dynamics 365 Field Service、Dynamics 365 Customer Insights - Journeys 和 Dynamics 365 Project Service Automation）的逻辑分组。 管理员可使用业务部门基于应用程序的使用者和每条记录的负责人控制对记录的访问。 业务部门对应于组织的部门，所以如果组织围绕拥有单独产品、客户和细分市场的部门构建，您可能会考虑创建业务部门。
业务部门对 Dynamics 365 Customer Insights - Journeys 的影响
业务部门的一般影响
有关业务部门在 Dynamics 365 中的模型驱动应用中的工作原理的完整详细信息，请参阅创建或编辑业务部门。 下面是与了解业务部门有关的概念的快速摘要：
- 每位用户仅属于一个业务部门。
- 每个记录与记录负责人属于同一个业务部门。 记录负责人可以是用户或团队。 默认情况下，记录负责人是创建记录的用户，虽然拥有足够权限的用户可以重新分派记录。
- 业务部门可以分层。 顶级业务部门称为组织业务部门；默认情况下，此类业务部门默认创建且不可删除。 在简单设置中，这可能是唯一存在的业务部门。 在稍微复杂的设置中，此业务部门下面可能有一层业务部门（也会调用这些业务部门）。 复杂设置可能有完整树，此类树有由分层业务部门构成的多个分支。
- 受限用户具有为其授予相关实体的用户级访问权限的安全角色。 这将其访问权限限制为仅包括自身负责的记录。
- 标准用户具有为其授予相关实体的业务部门级访问权限的安全角色。 因此，其可以访问属于自己的业务部门中的其他用户的记录（业务部门访问权限）。
- 高级用户（如经理）具有为其授予相关实体的父级访问权限的安全角色。 因此，其可以访问属于自己的业务部门和所有子（下层）业务部门中的用户的记录。
- 特权用户（如管理员）具有为其授予相关实体的组织级访问权限的安全角色。 这允许他们访问属于所有业务部门的记录。
- 团队也可以与业务部门合并来影响记录访问权限。 记录可以由团队而不是用户负责，在此情况下，记录成为团队的业务部门的一部分。 同样，团队可以合并来自不同业务部门的用户，在此情况下，该团队的成员可查看其他团队成员的记录，就像他们属于同一个业务部门。 详细信息：管理团队