Устранение распространенных проблем с конфигурацией с помощью правил автоматического создания и обновления записей
В этой статье приводятся разрешения распространенных сценариев сбоя конфигурации с автоматическими правилами создания и обновления записей, из-за которых может произойти сбой или пропуск записи.
Сценарий 1
Пример. Настройка для автоматического создания и обновления правила записи
- Необходимо выбрать параметр "Создать контакт для неизвестного отправителя".
- Задайте критерии условия на Любая входящая электронная почта.
- Добавьте действие для создания дела, выберите "Просмотреть свойства" и задайте поля регистра для каждого варианта использования для бизнеса.
Ошибка 1 . "Случай отсутствует клиент"
В поле "Клиент" раздела CASE DETAILS значение учетной записи отправителей (электронная почта), как показано ниже.
Этот параметр приводит к следующей ошибке в системных заданиях:
В этом случае отсутствует клиент.
Разрешение ошибки 1
Чтобы устранить эту проблему, оставьте поле "Клиент" пустым или задайте для него значение {Sender(Email)}. Это позволяет системе автоматически создать контакт для неизвестного отправителя и связать его с делом.
Ошибка 2 — "Произошла ошибка"
Поле "Клиент" задано как {Senders Account(Email)}, а поле контакта — {Sender(Email)}.
Этот параметр приводит к следующей ошибке в системных заданиях:
Произошла ошибка. Повторите попытку этого действия. Если проблема продолжается, проверьте сообщество Dynamics 365 Майкрософт для решений или обратитесь к администратору Microsoft Dynamics 365 вашей организации. Наконец, можно связаться с служба поддержки Майкрософт.
Разрешение ошибки 2
Чтобы устранить эту проблему, оставьте поле "Клиент" пустым или задайте для него значение {Sender(Email)}. Это позволяет системе автоматически создать контакт для неизвестного отправителя и связать его с делом.
Ошибка 3. "Указанный контакт не принадлежит контакту, указанному в поле клиента".
Поля "Клиент " и "Контакт" задаются как {Sender(Email)}.
Этот параметр приводит к следующей ошибке в системных заданиях:
Указанный контакт не принадлежит контакту, указанному в поле клиента. Удалите значение из поля контакта или выберите контакт, связанный с выбранным клиентом, и повторите попытку.
Разрешение ошибки 3
Чтобы устранить эту проблему, оставьте поле контакта пустым и задайте поле "Клиент " пустым или {Sender(Email)}.
Шаги проверки
Необходимо проверить действия конфигурации и проверки, описанные в следующей таблице, чтобы понять основную причину проблемы и устранить ее.
| Параметр в правиле автоматического создания и обновления записи в управлении сервисом | Если выбрано как | Шаги проверки | Результат |
|---|---|---|---|
| Создать обращение, если для клиента существует действительный объем обслуживания | Да | Проверить, что существует активный объем обслуживания для этого клиента. Допустимое активное право оценивается следующим образом: если отправитель сообщения электронной почты является контактом с родительской учетной записью, то служба клиентов Dynamics 365 создает случай, если родительская учетная запись контакта имеет допустимое право, а контакт указан в разделе "Контакты" права или , если раздел контактов пуст (то есть право применимо ко всем контактам для клиента). |
Создается случай. |
| Создавать обращения из сообщений электронной почты от неизвестных отправителей | Да | Для всех сообщений электронной почты от неизвестных отправителей | — создается случай. — Контакт также создается для неизвестного отправителя. |
| Да | Для входящей электронной почты с адресом электронной почты неактивной организации или контакта | — создается случай. — активируется неактивная учетная запись или контакт. |
|
| No | Для входящей электронной почты с адресом электронной почты активной организации или контакта | Создается случай. | |
| No | Для входящей электронной почты, отправленной типом записи, отличным от организации или контакта | Регистр не создается. | |
| No | Для входящей электронной почты с адресом электронной почты неактивной организации или контакта | Регистр не создается. | |
| Создать обращение для действий, связанных с разрешенным обращением | Да | Для входящей электронной почты, связанной с разрешенным обращением | Создается случай. |
| Да | Для входящей электронной почты, связанной с активным обращением | Регистр не создается. |
Сценарий 2. Использование {Относительно (email)} в устаревшем интерфейсе не дает правильных данных в потоке
В устаревших элементах "Автоматическое создание записей и обновление правил" в Службе клиентов для поиска сущности (контакт или учетная запись), которая отправляет сообщение электронной почты, можно использовать полиморфный поиск отправителя (электронной почты ), который автоматически извлекает соответствующую сущность и отображает имя сущности. Полиморфные поиски — это поиски, в которых целью поиска является несколько видов сущностей. Например, он может указывать либо на контакт, либо на организацию. Однако в современных правилах автоматического создания и обновления записей этот автоматический дисплей не поддерживается, поэтому необходимо указать тип сущности, которую нужно извлечь вместе с полями для отображения из этой сущности.
Причина
Поток не использует значение {Относительно (email)} как устаревший рабочий процесс, так как выражения потока ссылались на значение данных из одной из полезных данных предыдущего шага потока. Например, если значение {В отношении (эл. почта)} пустое, когда начинается поток, значение полезной нагрузки шага триггера для {В отношении (эл. почта)} останется пустым. Даже если значение {Относительно(Email)} обновляется после создания дела, данные записи электронной почты обновляются, но полезные данные в потоке не обновляются. Таким образом, когда значение из полезной нагрузки упоминается в последующих шагах потока, оно остается пустым.
Решение
Если значение {Относительно (email)} используется в устаревших элементах правил, необходимо вручную обновить перенесенный поток, чтобы использовать идентификатор инцидента или идентификатор OData. Используйте идентификатор OData для полей, требующих ссылки на сущности или подстановки. Используйте уникальный идентификатор регистра для полей, требующих GUID.
Сценарий 3. Проблемы с отображением полиморфных подстановок в полях без поиска во время миграции из прежних версий в современные "правила автоматического создания и обновления записей"
Устаревший элемент "Автоматическое создание и обновление правил записи" с помощью полиморфных подстановок, таких как Отправитель, приводит к недопустимому поиску при назначении текстовому полю.
В устаревших элементах "Автоматическое создание и обновление правил" в Службе клиентов для поиска сущности (контакт или учетная запись), отправляющей сообщение электронной почты, можно использовать полиморфный поиск отправителя (электронной почты ), который автоматически извлекает соответствующую сущность и отображает имя сущности. Полиморфные поиски — это поиски, в которых целью поиска является несколько видов сущностей. Например, он может указывать либо на контакт, либо на организацию. Однако в современных "правилах автоматического создания и обновления записей" этот автоматический дисплей не поддерживается. Поэтому необходимо указать тип сущности, которую требуется извлечь вместе с полями, отображаемыми из этой сущности.
Причина
Классическое поведение рабочего процесса, используемое устаревшими "правилами автоматического создания записей и обновления", имеет множество скрытых действий. Например, автоматическое определение типа сущности и получение поля в качестве отображаемого имени, если параметр используется в строке, но возвращает идентификатор при назначении поля подстановки. Код миграции платформы, который использует "правила автоматического создания записей и обновления" при преобразовании из устаревших в современные рабочие процессы, не добавляет необходимые действия и поля.
Решение
Чтобы решить эту проблему,
- Обновите поиск до определенного типа.
- Используйте другое поле во входящей сущности, содержащее нужный текст.