Динамика CRM в сценарии службы поддержки с низким уровнем доверия - PullRequest
3 голосов
/ 16 июня 2011

Хорошо, представьте, что в банке есть колл-центр, заполненный персоналом с низким уровнем доверия.Персонал должен предоставлять клиентам базовые услуги по телефону.Сотрудники колл-центра принимают звонки от клиентов, задают им определенные вопросы безопасности, а затем каким-то образом обслуживают счета.

Теперь, с точки зрения клиента, банк проверяет, кто он, задаваявопросы безопасности.Это несколько отличается от точки зрения банка: он проверяет, что сотрудник колл-центра разговаривает с клиентом.

Почему эта разница важна?Банк хочет ограничить этих сотрудников с низким уровнем доверия, чтобы они не могли просматривать какие-либо детали счетов, пока клиент не позвонит им.Таким образом, сотрудник колл-центра не может просматривать данные учетной записи клиентов, которые просто не связались с ним и не обратились за обслуживанием.

Итак, вопрос в том, возможна ли такая настройка в Dynamics CRM 2011?Как можно было бы реализовать это?Некоторый уровень настройки был бы в порядке, но сделанное на заказ приложение, управляемое из данных CRM, - нет.

Я думаю, что, возможно, возможно создать пользовательский компонент, который временно изменяет права пользователя на запись (ивсе его дети) после ответа на некоторые вопросы безопасности.Тем не менее, я даже не уверен, что безопасность на основе записей (помимо владения) поддерживается в CRM ...?Я полагаю, что можно временно передать право собственности на пользователя.Разве это разумно?

Обратите внимание: Простое скрытие видов и поиск кнопок в графическом интерфейсе - не тот уровень безопасности, который мы здесь ищем.Мы стремимся буквально ограничить доступ пользователей к рассматриваемым записям.

Ответы [ 3 ]

1 голос
/ 16 июня 2011

Я вижу несколько вариантов:

  1. Работа в рамках модели разрешений. Это может сработать. Вы можете ограничить доступ по умолчанию, а затем иметь другую сущность, в которую вы будете вводить данные учетной записи, плагин будет запускать и проверять детали, а затем делиться записью с текущим пользователем. Я, однако, был бы немного обеспокоен тем, как будет работать разделение. Что бы вызвать это? Будет ли процесс, который просто запускается вне CRM и периодически делит записи? Что делать, если этот процесс не удается? У нас также были проблемы с производительностью в этом типе модели ... CRM, кажется, выполняет большую часть работы каждый раз, когда права отдельной записи изменяются следующим образом.
  2. Переназначение владельца, как вы предлагаете. Нужно ли нескольким пользователям просматривать одни и те же данные? Нужно ли вести запись владельца по какой-либо другой причине (например, это учетная запись Джо, потому что он владелец).
  3. Работа исключительно с плагинами. Вы можете зарегистрировать плагин в Retrieve и RetrieveMultiple записи. Этот плагин может отфильтровать все детали, которые вы хотите скрыть от конечного пользователя. Когда пользователю необходимо просмотреть остальные данные, они заполняют форму или диалог или что-то с данными. Эти данные затем включаются в вызов Retrieve для записи. Плагин проверяет наличие скрытых данных, проверяет их наличие и корректность, затем удаляет их и позволяет продолжить запрос, только на этот раз он извлекает все атрибуты и форма заполняется, как и ожидалось.
1 голос
/ 30 ноября 2012

Если бы мне пришлось реализовать такой сценарий, я бы создал запись доступа клиента (new_custaccess), которая связана с записью клиента (new_customer).Для этого примера - оставаясь простым - я собираюсь предположить, что у клиента есть простой код доступа, который он должен предоставить, прежде чем сотрудник банка (Оператор) сможет получить доступ к записи.Код доступа хранится в new_custaccess в поле (new_secretcode).

Безопасность заключается в том, что Оператор не имеет привилегий для new_customer и привилегий чтения / обновления для new_custaccess.

В new_custaccess есть одно поле (new_secretcodeoperator), которое оператор может обновить.Все остальные поля запрещены для обновления (и, при необходимости, чтения) для Оператора.

Когда Клиент звонит, и Оператор ищет соответствующую запись new_custaccess.Как только они находят запись, они вводят предоставленный Заказчиком секретный код в поле new_secretcode и делают сохранение.

Запрос Pre-Update выполняется для new_custaccess в контексте пользователя с полными привилегиями (назовите его MASTER, дляздесь весело.) Этот плагин проверяет, соответствует ли предоставленный код секретному коду.Если этого не произойдет, выдается ошибка, и оператор может повторить попытку.Если он совпадает, плагин удаляет поле new_secretcodeoperator из записи, чтобы сохранить его от сохранения значения.Он также передает соответствующее разрешение на запись new_customer соответствующему оператору.

Оператор теперь имеет доступ к записи клиента (вам нужно будет решить, каскадировать разрешения или делиться для каждой записи - это решение выходит за рамкиэто обсуждение.)

Теперь нам нужно разобраться с отзывом разрешения на запись Клиента.Я бы справился с этим, имея сущность new_customeraccess, которая генерируется предыдущим плагином всякий раз, когда предоставляется доступ к записи о клиенте.Рабочий процесс должен запускаться при создании new_customeraccess, в результате которого new_customeraccess обновляется каждые 20 минут (или в любое другое время, которое предпочитает клиент.)

Плагин регистрируется при обновлении new_customeraccess, который запускается, когда поле обновляется рабочим процессом.модифицируется.Этот плагин будет определять - по любым критериям, выбранным бизнесом - продолжать ли совместное использование или отменять совместное использование.

Я бы также создал всплывающее окно на основе javascript / html с ленты new_customer, чтобы завершить совместное использование.обновив поле на new_customeraccess.Предоставьте оператору ограниченные права на обновление для new_customeraccess с помощью безопасности на уровне поля.

Это должно выполнить то, что вы хотите, не выходя за пределы стандартной модели настройки CRM.Не совсем уверен, где вы проведете линию на заказ, но это, вероятно, так близко, как вы доберетесь до OOTB.Несколько плагинов - это все, что вам нужно для C #.И единственный JavaScript будет для удобства использования, а не функциональности.

Дайте мне знать, если у вас есть вопросы.

1 голос
/ 16 июня 2011

Отказ от ответственности: этот ответ основан на большом опыте работы с CRM 4.0 и чтении заметок о выпуске за 2011 год.

Краткий ответ: нет.

Длинный ответ: да, но настройка будет серьезной. Самый простой вариант, который приходит на ум, заключается в том, что процесс аутентификации выполняется в виде специальной страницы asp.net, которая либо а) использует служебную учетную запись для переназначения объекта индивидууму, а затем возвращает их в соответствующий CRM. форма, а затем плагин, который переназначает его обратно при сохранении изменений или же b) имеет свой собственный набор форм для обновления и извлечения информации в качестве учетной записи службы, и делает это только после ответа на вопросы безопасности.

Кроме того, в CRM 4.0 практически невозможна любая «скриптовая» форма. Я считаю, что 2011 год немного улучшился, но то, что я видел, все еще не внушает оптимизма. Использование CRM в контакт-центре для нас означало инвестирование в стороннее программное обеспечение для создания форм и создание индивидуальных форм, которые можно запускать из CRM и возвращать данные через веб-сервисы (которые впечатляюще гибки). Мы используем только интерфейс CRM для просмотра исторических запросов - даже большинство обновлений вызывают одну из сделанных на заказ форм.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...