Dynamics crm 如何同时为两个用户/团队分配R/W所有权

我正在CRM中设计一个审批系统，需要一些关于安全设计的输入。我使用的实体具有用户/团队级别的R/W权限。整体实施有点复杂，但为了保持这个问题简单，考虑以下两个方面涉及的系统：

请求者：需要对他创建的请求进行R/W访问

批准者团队：这些是预定义的团队，其用户将批准/拒绝请求。需要R/W访问需要其批准的请求

问题： 我如何处理同时为请求者和批准者团队提供R/W访问？由于CRM中的记录不能有多个所有者，因此所有者字段一次只能包含其中任何一个（请求者或批准者团队）

我可以使用共享功能想出两种解决方案，并希望确认我的理解：

a.将请求者设置为记录所有者，并以编程方式与审批者团队共享记录。这种方法的问题是，即使我与Approver团队共享记录，我也无法在主表单上显示共享详细信息（这是一项要求）

b.将审批者团队设置为记录所有者，并使用访问模板以编程方式与请求者共享记录

有没有更好的解决方案来处理这个需求，以防我错过任何OOB的可能性

您的选择a最有意义：请求者作为创建者，应该拥有请求。Approver只是对请求进行操作，因此它应该与共享

关于显示共享详细信息，您可以在以下表单中放置子网格：

将团队模板添加到实体表单中

确保您具有系统管理员安全角色或 Microsoft Dynamics 365中的等效权限

检查您的安全角色

[在链接页面中阅读更多信息]

由于请求者是用户，审批者是团队，OOB您只能执行选项b（分配给团队，通过Access团队与用户共享）

---

我想不出一个干净的解决方案，包括列举团队成员并对每个成员采取行动，所以我不会建议。

< P>我相信你可以用一点点编码来解决问题（我不确定你是否介意编码，但是我们在StAcExcel上，所以我想你应该考虑一下）。 首先，设计取决于一个简单的问题——这个请求应该与多个团队共享，还是只与单个团队共享？单一团队很简单-只需在请求上添加一个查找，它将指向一个团队。当这个团队被填满时（我假设这个团队的选择是自动完成的，但这并不重要，因为在任何情况下，你无论如何都必须选择这个团队），你运行一个简单的插件来共享这个团队的记录。使用SDK共享非常简单，只需使用GrantAccessRequest：

var grantAccessRequest = new GrantAccessRequest
{
    PrincipalAccess = new PrincipalAccess
    {
        AccessMask = AccessRights.ReadAccess | AccessRights.WriteAccess,
        Principal = teamEntityReference
    },
    Target = requestReference
};

因此，在请求的形式上，您将保留请求的所有者，并将有一个指向处理此请求的团队的查找。当然，您可以通过例如在接受或拒绝请求或更改请求的查找时取消共享等方式进一步提高POA表的性能。这将使POA表更加愉快，因为共享大量记录可能会导致该表的快速增长，因此，如果不再需要共享，则取消共享记录非常重要

如果您想共享给多个团队，您仍然可以在您的请求和团队之间创建一个N:N关系，并且只需在请求和团队之间的关联消息上的插件中共享您的请求（在用户引入Access团队之前，这是一个标准选项，现在仍然是团队的唯一选项）。此关系可以在请求表单上显示为子网格（看起来像access团队子网格）

当然，为了防止用户自己共享请求记录（在这种情况下，您的查找/子网格中没有团队），他们不应该拥有共享权限。插件应该在管理上下文中进行共享

更新： 至于评论中的POA注意事项：这两种解决方案都将使您的POA增长，因为对于这两种解决方案，您必须与团队或用户共享请求。如果您使用access team，则每个请求仍将有一个POA条目（每年10万条条目）。我相信这里最重要的事情是当请求结束其生命周期时会发生什么。如果团队不必看到它，那么在它被接受/拒绝之后，你只需要有一个机制（插件或一些及时运行的自定义应用程序），它将取消共享所有不再需要共享的请求，保持POA表的合理大小

还有另一种处理场景的方法，它不需要那么多共享/取消共享逻辑。您可以在与请求的1:N家长关系中创建“请求接受”实体。由于它是父母关系，拥有请求的用户将看到所有“请求接受”和“请求接受”将由适当的团队拥有（因此只有该团队有权访问）。当然，我对业务逻辑一无所知，但我假设“请求接受”只能包含与团队相关的信息，这些信息可以在插件或工作流中复制

更新2：正如我刚才看到的，您不能在稍后阶段取消共享记录。但我假设在某个时间点，请求已经完成/接受/完成/拒绝或者其他什么。如果此时团队和用户都应该可以访问此请求，那么创建某种单独的实体“归档请求”可能是一件好事，它不会被共享，只是为所有有兴趣查看此信息和删除的主体克隆