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

时间:2017-04-13 08:49:42

标签: dynamics-crm dynamics-crm-2013 dynamics-crm-2015

我正在设计CRM中的审批系统,并需要对安全设计进行一些输入。我使用的实体具有用户/团队级别的R / W权限。整体实施有点复杂,但为了简化这个问题,请考虑系统中涉及的以下两方:

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

审批人 团队:这些是预定义的团队,其用户将批准/拒绝该请求。需要R / W访问需要他们批准的请求。

问题: 如何同时为请求者和审批者团队提供R / W访问?由于我们无法在CRM中拥有多个记录所有者,因此所有者字段一次只能包含其中任何一个(请求者或审批者团队)。

我可以使用共享功能想出两个解决方案,并希望确认我的理解:

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

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

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

2 个答案:

答案 0 :(得分:1)

您的选项 a 最有意义:请求者是创建者,应该拥有请求。审批人只是对请求采取行动,因此应与。

共享

关于显示共享详细信息,您可以在表单中添加子网格:https://www.microsoft.com/en-us/dynamics/crm-customer-center/create-a-team-template-and-add-to-an-entity-form.aspx

<击>   

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

     

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

     

检查您的安全角色

     

[在链接页面中阅读更多内容]   

由于请求者是用户,审批者是团队,OOB您只能选择 b (分配给团队,通过访问团队与用户共享)。

我无法想到任何涉及列举团队成员并采取行动的清洁解决方案,因此我不会建议。

答案 1 :(得分:1)

我相信你可以让解决方案A使用一点点编码(我不确定你是否不介意编码,但我们在StackOverflow,所以我认为你应该考虑这一点)。 首先,设计取决于简单的问题 - 这个请求是应该与多个团队共享,还是只与单个团队共享?单一团队很简单 - 只需在Request上添加一个查找,即指向一个团队。当这个团队被填补时(我假设这个团队的选择是以某种方式自动完成的,但无论如何你无论如何都必须以某种方式选择团队),你运行一个共享记录的简单插件对于这个团队。使用SDK共享非常简单,只需使用GrantAccessRequest:

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

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

如果您想与多个团队分享,您仍然可以在您的请求和团队之间建立N:N关系,并在请求和团队之间的关联消息插件中共享您的请求(这是Access Teams之前的标准选项)为用户介绍,仍然是团队的唯一选择)。这种关系可以在请求表单上显示为子网格(它看起来像访问团队子网格)。

当然,为了防止用户自己共享请求记录(在这种情况下,您的查找/子网格中没有Team),他们不应该具有共享权限。该插件应该在管理环境中进行共享。

更新: 至于评论中的POA考虑因素:两种解决方案都会使您的POA增长,因为对于这两种解决方案,您必须与团队或用户共享请求。如果您将使用访问团队,您仍然会为每个请求提供一个POA条目(每年100K条目)。我相信这里最重要的是Request在它结束生命周期时会发生什么。如果团队不必看到它,在接受/拒绝后,你应该只是有一个机制(插件或某些及时运行的自定义应用程序),它将取消共享不再需要共享的所有请求,保持您的POA表格大小合适。

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

UPDATE2:正如我刚才看到的那样,你不能在以后的版本中取消记录。但我假设在某个时间点请求已完成/接受/完成/拒绝或其他任何事情。如果此时团队和用户都应该可以访问此请求,那么创建某种单独的实体“存档请求”可能是一件好事,这些实体不会被共享,只是为所有有兴趣看到的主体克隆此信息和删除原始请求。这个想法有很多变化,我希望你能得到它并根据你的场景进行调整