PAYATHON 2026

D365 中如何为超过50个团队配置 Dataverse 数据隔离与四级审批路由？

数据小许

可以让业务团队持有记录，通过审批字段筛选待办。团队超过50个，也不意味着要建立同样数量的 Business Units。团队数据访问可以由 owner team 和安全角色控制，待办则按当前审批层级、当前审批人和审批状态筛选。

审批人既然能在主视图中查看团队全部记录，就已经拥有这些记录的读取权限。“只显示自己阶段的待办”应通过视图筛选实现，不能通过另一个安全角色收回已经获得的读取权限。

1. owning team 可以用于团队隔离吗？

可以，前提是业务表采用 User or team owned 所有权类型，并使用能够持有记录的 owner team。Access team 不能持有记录，也不能分配安全角色。Microsoft Learn：Owner team 与 Access team

可以按以下方式配置：

  1. 每个业务团队对应一个 owner team，将提交人和4名审批人加入该团队。
  2. 为团队分配具有业务表基础读取权限的角色，通常从 User（Basic）级别的 Read 开始配置。
  3. 检查该角色的 Member’s privilege inheritance 设置。若权限只需作用于团队持有的记录，可以采用 Team privileges only；若成员还需创建或处理个人持有的记录，应结合实际操作配置并验证。
  4. 提交后保持记录归业务团队所有，审批流转时更新审批信息，无需将记录依次转交给每名审批人。

团队角色的 User 级权限需要与成员继承设置配合使用，不能简单理解为“User 级只能读个人记录”。Microsoft Learn：安全角色与权限

Business Units 适合表达部门层级和更大范围的管理边界。如果只是为了隔离50多个平级团队，可以让这些团队位于同一个 Business Unit，再通过团队所有权控制访问。每个 team 仍然属于某个 Business Unit，但不必为每个团队新建一个。

还要检查用户的直接角色、其他团队成员身份、记录共享和层级安全。额外的访问授权可能使用户看到其他团队的数据。特别是业务表上的 Business Unit、Parent: Child Business Unit 或 Organization 级 Read，可能扩大可读范围。Microsoft Learn：Dataverse 所有权安全模型

如果草稿也必须遵守团队隔离，应在创建时就确定 owner。若提交时才分配团队，需要单独验证提交前的访问权限和重新分配后的共享情况。

2. 当前审批层级字段是否适合驱动视图？

适合。对于已经实现的四级审批，可以保留现有 Power Automate 流程，由流程维护当前状态。建议至少区分以下信息，字段名称可按现有表结构调整：

信息用途
当前审批层级表示目前处于第几级审批
审批状态区分待审批、已通过、已拒绝等状态
当前审批人明确当前由谁处理

只保存“当前审批层级”也能筛选阶段，但系统还需要知道该团队这一层级对应谁。可以将“团队＋审批层级 → 审批人”的关系放在配置表中，让流程据此更新当前审批人，避免在流程里维护50多组条件分支。

流程推进时，应协调更新层级、状态和当前审批人。最终通过或拒绝后，清除当前待办指派或更新为明确的终态，防止记录继续出现在待审批视图。

如果需要保留每一级的处理人、意见和时间，可以增加关联审批历史表。主记录保留当前状态，历史记录保存每次处理结果。如果现有功能已经满足需求，无需仅为视图筛选重做审批流程。

3. 同一团队的多个角色能否分别限制审批阶段？

不能靠标准安全角色按“当前审批层级”的值限制记录读取。Dataverse 安全角色主要控制表操作权限及访问范围，不提供可直接配置为“仅当审批层级为2时允许读取”的条件权限。

安全角色权限会叠加，团队成员也会获得团队角色授予的权限。因此，把 Submitter、Tier1Approver、Tier2Approver 等角色全部分配给包含5名成员的同一个团队，无法让成员各自只继承其中一个角色。Microsoft Learn：团队角色与成员权限

可以按以下方式分工：

  • 业务团队角色：授予团队记录的共同读取权限。
  • 提交人或审批人角色：按人员实际职责分配，用于所需操作权限和视图入口；也可以通过职责一致的独立团队分配。
  • 审批配置：确定每个团队、每个层级对应的审批人。
  • 待审批视图：根据状态、层级或当前审批人显示待办。

还要区分读取权限和批准权限。如果所有审批人都能读取团队记录，但只能处理自己的当前阶段，受控审批入口应校验实际处理人、当前状态和当前层级。不要仅依赖隐藏按钮或视图过滤。

如果普通用户拥有业务表 Write 权限，还应检查其是否能够直接修改审批状态、层级或审批人字段。可结合列级安全和受控后端更新设计，避免绕过审批流程。

4. 超过50个团队时，视图如何维护？

优先复用少量公共视图，避免按“团队×审批层级”复制视图。

可以先保留两类入口：

  • 团队全部记录：不增加审批阶段条件，由 Dataverse 权限决定哪些记录可以返回。
  • 我的待审批记录：审批状态为待审批，并且当前审批人为当前用户。

如果界面需要四个独立阶段入口，再增加第1至第4级待审批视图，各自附加对应层级条件即可。团队隔离仍由权限提供，不需要在每个视图中硬编码团队名称。

下面是“我的待审批记录”的 FetchXML 示例。表名和字段名均为示例，100000000 假设是审批状态 Choice 中“待审批”的实际值，使用前必须替换为环境中的定义：

<fetch>
  <entity name="new_request">
    <attribute name="new_requestid" />
    <attribute name="new_name" />
    <attribute name="new_currentapprovaltier" />
    <attribute name="new_currentapprover" />
    <filter type="and">
      <condition attribute="new_approvalstatus"
                 operator="eq"
                 value="100000000" />
      <condition attribute="new_currentapprover"
                 operator="eq-userid" />
    </filter>
  </entity>
</fetch>

示例假设 new_currentapprover 是指向用户的 lookup。eq-userid 用于与当前执行查询的用户匹配；如果改为审批团队指派，则需要相应调整数据模型和查询。Microsoft Learn：FetchXML 条件运算符

若环境已启用 EnableRoleBasedSystemViews，可以在非默认公共视图的 View settings 中选择 Specific security roles，控制视图选择器中的入口。默认公共视图不能通过该设置绑定角色，而且这种功能只影响视图入口，不会改变记录访问权限。Microsoft Learn：管理公共系统视图访问

5. 上线前如何验证？

用两个不同团队的普通业务账号验证以下行为，不要使用 System Administrator 账号代替：

  1. 提交人和4名审批人都能在主视图看到本团队全部记录。
  2. 待审批视图只返回当前分配给该用户的待办，推进阶段后待办同步变化。
  3. 切换视图、搜索或直接打开另一团队的记录链接，仍无法读取记录。
  4. 非当前审批人即使能打开本团队记录，也无法提交有效审批或直接篡改审批状态。
  5. 流程重试、重复响应和过期响应不会重复推进审批；若异步更新失败，能够定位并恢复状态。

视图显示正确不代表权限配置正确，还需要验证团队隔离和审批执行权限。

备注：内容仅供参考。