Dynamics crm 低信任帮助台场景中的Dynamics CRM

好吧，假设一家银行有一个呼叫中心，里面都是信任度低的员工。员工需要通过电话向客户提供基本服务。呼叫中心工作人员接听客户的电话，向他们询问某些安全问题，然后以某种方式为客户提供服务

现在，从客户的角度来看，银行通过询问安全问题来验证他们是谁。这与银行的观点略有不同：这是在验证呼叫中心员工是否在与客户交谈

为什么这种差异很重要？银行希望限制这些信任度低的员工，因此在客户打电话给他们之前，他们无法查看账户的任何详细信息。因此，呼叫中心员工无法浏览客户的账户详细信息，这些客户不仅与他联系并要求提供服务

因此，问题是： 这种设置在Dynamics CRM 2011中是否可行？如何着手实施它？某种程度的定制是可以的，但由CRM数据驱动的定制应用程序则不行

我在想，也许可以创建一个自定义组件，在回答一些安全问题后临时修改用户对记录（及其所有子项）的权限。然而，我甚至不确定CRM中是否支持基于记录的安全性（所有权之外）。。。？我想可以暂时将所有权分配给用户。这明智吗

---

请注意：简单地从GUI中隐藏视图和查找按钮并不是我们想要的那种安全级别。我们希望严格限制用户访问相关记录。

免责声明：此答案基于大量CRM 4.0经验和阅读2011年发行说明

简短回答：没有

长句回答：是的，但定制将是主要的。想到的“最简单”选项是，身份验证过程作为定制的asp.net页面执行，该页面a）使用服务帐户将实体重新分配给个人，然后将其返回到相关的CRM表单，然后是一个插件，在保存更改时重新分配 或 b） 它有自己的一套表单来作为服务帐户更新和检索信息，并且只有在回答了安全问题后才能这样做

---

另外，在CRM 4.0中，几乎不可能使用任何类型的“脚本化”表单。我相信2011年在这方面略有改善，但我所看到的仍然不令人鼓舞。在我们的联系中心使用CRM意味着投资一款第三方表单构建软件，创建定制表单，可以从CRM启动，并通过web服务返回数据（非常灵活）。我们仅使用CRM界面查看历史请求-即使大多数更新也会触发一个定制表单。

我可以看到几个选项：

在权限模型中工作。这可能行得通。您可以在默认情况下限制访问，然后拥有另一个实体，您可以在其中输入帐户详细信息，插件将运行并验证详细信息，然后将记录共享给当前用户。然而，我会有点担心，不分享会如何发挥作用。什么会触发它？是否会有一个流程只是在CRM之外运行，并定期取消共享记录。如果这个过程失败了怎么办？我们过去也有过这种型号的性能问题。。。每当单个记录的权限像这样更改时，CRM似乎都在幕后做很多工作

按照您的建议重新指定所有者。多个用户是否需要查看相同的数据？是否出于任何其他原因需要维护记录的所有者（例如，这是Joe的帐户，因为他是所有者）

专门使用插件。您可以在记录的Retrieve和RetrieveMultiple上注册插件。这个插件可以过滤掉你想对最终用户隐藏的所有细节。当用户需要查看其余数据时，他们会用数据填写表单、对话框或其他内容。然后，该数据将包含在记录的检索调用中。插件检查隐藏的数据，验证它是否存在并且正确，然后将其删除并让请求继续，只是这次它检索所有属性，表单按预期填充

---

如果我要实现这样一个场景，我将创建一个客户访问记录（new_custaccess），该记录链接到客户记录（new_customer）。对于这个例子——保持简单——我将假设客户在银行员工（操作员）访问记录之前必须提供一个简单的访问代码。访问代码存储在一个字段中的new_custaccess上（new_secretcode）

安全性是操作员对新客户没有权限，对新客户访问没有读取/更新权限

在new_custaccess上有一个字段（new_secretcodeoperator），操作员可以更新该字段。所有其他字段都限制由操作员进行更新（如果合适，还限制为读取）

当客户打电话并且接线员搜索适当的新访问记录时。找到记录后，他们将客户提供的密码输入字段new_secretcode并保存

更新前查询在具有完全权限的用户（此处称之为MASTER）的上下文中对new_custaccess执行。该插件检查提供的代码是否与密码匹配。如果没有，它会抛出一个错误，操作员可以重试。如果与插件匹配，则从记录中删除字段new_secretcodeoperator，以防止其保存值。它还将记录新客户的适当权限共享给相应的运营商

操作员现在可以访问客户记录（您必须决定是对每个记录级联权限还是共享-该决定超出了本文的讨论范围。）

我们现在需要处理撤销私募股权的问题