3

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

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

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

所以问题是：这种设置在 Dynamics CRM 2011 中是否可行？一个人将如何实施它？一定程度的定制是可以的，但从 CRM 数据驱动的定制应用程序则不行。

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

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

4

3 回答 3

1

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

简短的回答：没有。

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

顺便说一句，在 CRM 4.0 中几乎不可能出现任何类型的“脚本化”形式。我相信 2011 年在这方面略有改进，但我所看到的仍然不令人鼓舞。对我们来说，在联络中心使用 CRM 意味着投资购买第三方表单构建软件并创建可以从 CRM 启动并通过 Web 服务（非常灵活）返回数据的定制表单。我们仅使用 CRM 界面查看历史请求 - 即使大多数更新都会触发其中一种定制表单。

于 2011-06-16T15:08:45.683 回答
1

如果我要实现这样的场景，我将创建一个链接到客户记录 (new_customer) 的客户访问记录 (new_custaccess)。对于此示例 - 保持简单 - 我将假设客户具有他们必须提供的简单访问代码，然后银行员工（操作员）才能访问记录。访问代码存储在 new_custaccess 的字段 (new_secretcode) 中。

安全性在于 Operator 对 new_customer 没有权限，对 new_custaccess 没有读取/更新权限。

new_custaccess 上有一个字段 (new_secretcodeoperator)，操作员可以更新。所有其他字段都被限制更新（并且，如果合适的话，读取）给操作员。

当客户呼叫并且操作员搜索适当的 new_custaccess 记录时。一旦他们找到记录，他们就会将客户提供的密码输入字段 new_secretcode 并进行保存。

更新前查询在具有完全权限的用户的上下文中执行 new_custaccess（称之为 MASTER，在这里很有趣。）该插件检查提供的代码是否与密码匹配。如果不是，它会引发错误并且操作员可以重试。如果确实匹配，插件会从记录中删除字段 new_secretcodeoperator，以防止它保存值。它还将记录 new_customer 的适当权限共享给适当的操作员。

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

我们现在需要处理撤销对客户记录的许可。我将通过拥有一个实体 new_customeraccess 来处理这个问题，该实体由前一个插件在授予客户记录访问权限时生成。应在创建 new_customeraccess 时触发工作流，导致 new_customeraccess 每 20 分钟（或客户喜欢的任何时间）更新一次。

插件在 new_customeraccess 的更新上注册，当工作流更新的字段被修改时触发。该插件将通过业务决定的任何标准来确定是继续共享还是撤销共享。

我还将从 new_customer 功能区创建一些基于 javascript/html 的弹出窗口，以通过更新 new_customeraccess 上的字段来结束共享。通过字段级安全性为操作员提供关于 new_customeraccess 的有限更新权限。

这应该可以在不超出标准 CRM 定制模型的情况下完成您想要的。不完全确定您在定制上划定界限，但这可能与您将到达的 OOTB 一样接近。几个插件就是您需要的所有 C#。唯一的 JavaScript 将用于可用性，而不是功能。

如果您有任何问题，请告诉我。

于 2012-11-30T05:28:13.803 回答
1

我可以看到几个选项：

  1. 在权限模型中工作。这可以工作。您可以默认限制访问，然后在另一个实体中输入帐户详细信息，插件将运行并验证详细信息，然后将记录共享给当前用户。但是，我有点担心取消共享的工作方式。什么会触发它？是否会有一个仅在 CRM 之外运行并定期取消共享记录的流程。如果这个过程失败了怎么办？我们过去也遇到过这种模型的性能问题......每次像这样更改单个记录的权限时，CRM 似乎都会在后台做很多工作。
  2. 按照您的建议重新分配所有者。多个用户是否需要查看相同的数据？是否出于任何其他原因需要维护记录的所有者（例如，这是 Joe 的帐户，因为他是所有者）。
  3. 专门使用插件。您可以在记录的 Retrieve 和 RetrieveMultiple 上注册一个插件。这个插件可以过滤掉你想对最终用户隐藏的所有细节。当用户需要查看其余数据时，他们会用数据填写表单或对话框或其他内容。然后，此数据将包含在记录的检索调用中。该插件检查隐藏的数据，验证它是否存在并且正确，然后将其剥离并让请求继续，只是这一次它检索所有属性，并且表单按预期填充。
于 2011-06-16T15:11:34.643 回答