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