【问题标题】:Dynamics CRM in low-trust helpdesk scenario低信任帮助台场景中的 Dynamics CRM
【发布时间】:2011-06-16 13:18:10
【问题描述】:

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

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

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

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

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

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

【问题讨论】:

  • 我认为现场级别的安全性可能会有所帮助,因此呼叫中心用户仍然可以搜索客户/帐户,但在通过自定义安全检查之前看不到任何详细信息。嗯。也许一个对话框可以实现安全检查。尽管如此,这似乎是在将圆钉钉入方孔中。此外,管理大量字段/实体的字段级安全性可能也不是很有趣。

标签: dynamics-crm dynamics-crm-2011


【解决方案1】:

我可以看到几个选项:

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

【讨论】:

  • 1.啊,好吧,我忘了分享,这似乎是给用户临时访问权限的更好方法。取消分享可能(在此示例场景中)与客户挂断电话相关联。
  • 2.我想这并不比 1 更好,但对于多用户访问来说更具限制性。
  • 3.我认为这种方法的问题是 RetrieveMultiple 可以将结果作为非常复杂的查询的一部分返回。依靠插件过滤掉用户不应该看到的东西可能非常困难 - 我们永远无法确定没有其他方法可以绕过已放置的块。
【解决方案2】:

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

简短回答:不。

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

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

【讨论】:

    【解决方案3】:

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

    安全性在于操作员对 new_customer 没有权限,对 new_custaccess 没有读取/更新权限。

    new_custaccess 上有一个字段(new_secretcodeoperator),操作员可以更新。所有其他字段都被限制更新(并在适当情况下读取)给 Operator。

    当客户致电并且操作员搜索适当的 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 上的字段来结束共享。通过字段级安全性为 Operator 提供关于 new_customeraccess 的有限更新权限。

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

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2012-08-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2023-03-19
      • 1970-01-01
      相关资源
      最近更新 更多