Вопросы и ответы по инструменту миграции

Инструмент миграции для правил автоматического создания записей и соглашений об уровне обслуживания (SLA)

Кто может получить доступ к инструменту миграции или запустить его?

Администраторы и пользователи, имеющие роли менеджера CSR, могут запустить инструмент миграции.

Активируются ли автоматически перенесенные правила после миграции?

№ После завершения миграции необходимо вручную активировать перенесенные правила.

Могу ли я по-прежнему использовать свои устаревшие правила после истечения срока устаревания?

Да. Активные устаревшие правила продолжают работать после крайнего срока поддержки, пока правила не будут деактивированы. Однако после прекращения поддержки возможности редактирования и поддержки прекращаются.

Могу ли я активировать правило с незавершенным состоянием миграции?

№ Перенесенное правило активируется только при переключении Отметить как завершенное на Да после того, как вы проверите незавершенное правило и устраните все имеющиеся проблемы. В этом случае правило считается успешно перенесенным.

Деактивируется ли устаревшее правило после миграции?

• Да, для автоматического создания записей. Когда вы активируете перенесенное правило автоматического создания записей в едином интерфейсе, соответствующее устаревшее правило будет деактивировано.
• Нет для соглашений SLA. Когда вы активируете перенесенное правило SLA в едином интерфейсе, соответствующее устаревшее правило останется активным и два правила будут сосуществовать.

Что означает статус миграции "не завершено"?

• В разделе Сводка: в ходе всего процесса миграции не удалось успешно завершить миграцию всех выбранных правил.
• Рядом с правилом: перенос правила либо завершился сбоем, либо не может быть полностью завершен (что означает, что не удалось перенести один или несколько элементов или условий).

Где я могу найти список частично перенесенных правил, которые отслеживаются в инструменте миграции?

Правила, которые перенесены частично или определены как перенесенные не полностью, не считаются полностью перенесенными. Поэтому они отслеживаются как В ожидании в разделе Сводка. Только правила, миграция которых успешно завершена, учитываются в пункте Перенесенные.

Поддерживаются ли пользовательские формы или поля инструментом миграции?

• Да, для автоматического создания записей. Пользовательские сущности, поля, атрибуты и конфигурации поддерживаются инструментом миграции.
• Нет для соглашений SLA. Пользовательские сущности, поля, атрибуты и конфигурации не поддерживаются инструментом миграции. Чтобы завершить миграцию, пользователи должны изменить любые существующие процессы настройки, рабочие процессы, подключаемые модули или другой пользовательский код в пользовательских сущностях, полях, атрибутах и конфигурациях.

Нужна ли мне отдельная лицензия для Power Automate перед запуском миграции?

№ Для получения дополнительной информации о правилах лицензирования перейдите в раздел Каковы права использования Microsoft Power Apps и Power Automate для приложений Dynamics 365?

Некоторые из моих правил были перенесены неполностью или частично. Что делать?

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

Могу ли я повторно запустить инструмент миграции для определенного перенесенного правила?

Да, вы можете повторно запустить инструмент миграции для определенного перенесенного правила на основе следующих критериев:

• Для правил, которые не были перенесены или перенесены частично: выберите это же правило при повторном запуске средства миграции. При этом существующее правило, перенесенное со сбоем или неполностью, будет автоматически заменено новым перенесенным правилом.
• Для успешно перенесенных правил: удалите перенесенное правило в едином интерфейсе перед повторным запуском инструмента миграции.

Что произойдет после завершения миграции с существующими записями SLA, связанными с устаревшими соглашениями об уровне обслуживания?

• Если устаревшее соглашение об уровне обслуживания деактивировано после миграции: таймер будет продолжать работать до достижения конечного состояния для таких записей SLA. Однако функции Разрешить и Приостановить не будут работать.
• Если устаревшее соглашение об уровне обслуживания все еще находится в активном состоянии: существующие записи SLA, связанные с устаревшими соглашениями об уровне обслуживания, продолжат работать должным образом.
• Если вы хотите использовать соглашения об уровне обслуживания, созданные в приложениях единого интерфейса, для существующих записей: вам придется вручную обновить поле SLA до единого интерфейса или написать подключаемый модуль для обновления записей. Например, подключаемый модуль может иметь логику Modern Flow или Workflow.

Информацию о перенесенных правилах или потоках современного автоматического создания записей см. в разделе Вопросы и ответы об автоматическом создании записей.

Известные проблемы преобразования условий

В этом разделе описаны ключевые сценарии, в которых правила или элементы не могут успешно завершить миграцию.

Если у моих элементов правил или условий есть связанные сущности внутри предложения вложенной группы (и/или), будут ли они перенесены в единый интерфейс?

№ В настоящее время мы поддерживаем только один уровень иерархии связанных сущностей. Для успешного переноса таких элементов правил или условий необходимо удалить все связанные сущности в предложении группы перед переносом. Если вы не предпримете никаких действий, правило не будет выполнено во время шага Проверка перед переносом. Если вы решите продолжить миграцию, в правиле будет пустое условие для связанного элемента.

Пример: связанные сущности во вложенном групповом предложении

Представление веб-клиента перед миграцией

Условные обозначения:

a. Заголовок элемента.

Представление единого интерфейса после миграции

Условные обозначения:

2a. "_FailedMigration" добавляется к заголовку переносимого элемента.

2b. Тот же стандартный заполнитель Когда создано равно 2200-01-01 добавляется к условию.

Почему мои элементы правил или условия с полем DateType, в котором используется оператор "Not-On", дают сбой во время предварительной проверки и фактического переноса?

Оператор Not-On для типа данных Date не поддерживается в едином интерфейсе. Поэтому он не поддерживается как часть миграции. Чтобы решить эту проблему, вы можете изменить устаревшие элементы или условия с {not-on selecteddate} на {selecteddate less than and selecteddate greater than} в веб-клиенте перед повторным запуском инструмента миграции для соответствующего правила.

Пример: поле DateType, в котором используется оператор Not-On

Представление веб-клиента перед миграцией

Условные обозначения:

a. Заголовок элемента.

Представление единого интерфейса после миграции

Условные обозначения:

2a. "_FailedMigration" добавляется к заголовку переносимого элемента.

2b. Условие "Когда создано" равно 2200-01-01 добавляется к условию.

Почему данные в моем поле DateTime меняются во время миграции?

В едином интерфейсе нет отдельного поля времени. Поэтому поле DateTime изменится с элемента управления календаря на текстовое поле. Входные данные должны быть в определенном формате, как показано в примере ниже.

Пример: поле DateTime

Представление веб-клиента перед миграцией

Условные обозначения:

a. Поле Дата и время до миграции.

b. Поле Только дата до миграции.

Представление единого интерфейса после миграции

Условные обозначения:

a. Поле Дата и время после миграции.

b. Поле Только дата после миграции.

Почему после переноса в единый интерфейс некоторые поля оператора остаются пустыми?

Для типов данных подстановки только операторы равно, не равно, NULL и не NULL поддерживаются в едином интерфейсе и инструменте миграции. Операторы менее и не менее не поддерживаются в едином интерфейсе и следовательно не поддерживаются в инструменте миграции. Любые условия, имеющие операторы менее или не менее, преобразуются как связанные сущности после миграции. В едином интерфейсе они отображаются пустыми и их нельзя редактировать.

Пример: поля оператора "менее" и "не менее"

Представление веб-клиента перед миграцией

Условные обозначения:

a.Операторы менее.

Представление единого интерфейса после миграции

Условные обозначения:

b. Пустое поле оператора.

Заметка

При определении условия в центре обслуживания клиентов применяются следующие ограничения:

• Элемент управления "Выбор даты и времени" больше не доступен в условиях. Однако вы по-прежнему можете редактировать дату и время в текстовом поле.
• В настоящее время поддерживается только один уровень иерархии связанных сущностей. Однако в приложении можно выбирать вложенные связанные объекты.
• Связанная сущность внутри группы и/или предложения не поддерживается.
• Оператор Not-on для типа данных Дата не поддерживается.
• Для типа данных Подстановка поддерживаются только операторы равно, не равно, NULL и не NULL. Операторы менее и не менее не поддерживаются.

Могу ли я снова перенести правило после его активации?

• Да, для правил автоматического создания записей. Вы можете повторно перенести активированное правило, но сначала необходимо деактивировать и удалить его из единого интерфейса.
• Нет для соглашений SLA. После активации перенесенного правила SLA оно связывается с другой сущностью (например, с обращением) или используется. По умолчанию активированное правило успешно переносится. Прежде чем вы сможете снова перенести активированное правило, вам необходимо удалить его. Однако для правил SLA единого интерфейса существует ограничение. После того как правило будет связано с обращением или сущностью (то есть после того, как оно будет активировано один раз), его нельзя удалить, даже если оно деактивировано. Следовательно, правило нельзя перенести снова, если оно было ранее активировано или применено.

Могу ли я перенести устаревшие стандартные правила SLA?

№ Инструмент миграции поддерживает только расширенные правила SLA. Стандартные правила SLA больше не поддерживаются. Они больше не поддерживаются в едином интерфейсе и, следовательно, не поддерживаются в средстве миграции. Дополнительные сведения см. в разделе Стандартные соглашения SLA в Dynamics 365 Customer Service устарели.

Известные проблемы

Устаревание свойства канала

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

Если установлен флажок "Создать обращения для действий, связанных с разрешенным обращением", поведение отличается

• Устаревшее поведение: если в электронном письме есть связанный случай, который был разрешен после указанного времени, решенный случай по умолчанию повторно активируется. Настройка не требуется.
• Современное поведение: если в электронном письме есть связанное обращение, которое было разрешено после указанного времени, по умолчанию создается новое обращение. Для повторной активации существующего обращения вместо создания нового обращения требуется настройка.

Разница в поведении при выборе параметра "Создать обращение, если для клиента существует действительный объем обслуживания"

• Устаревшее поведение: если у отправителя электронного письма нет действительного объема обслуживания прав, а в электронном письме есть связанное обращение, существующее связанное обращение обновляется.
• Современное поведение: Если у отправителя электронной почты нет действительного объема обслуживания, поток не вызывается.

Разрывы в четности между рабочими процессами и потоками Power Automate (применимо только к настройке действий элемента правила)

• Выражения "First not null" не могут быть перенесены автоматически. Однако настройку можно вручную применить к потоку для миграции.
• Сопоставление отображаемого имени записи подстановки со строковым полем невозможно перенести автоматически. Однако настройку можно вручную применить к потоку для миграции.
• Поля участников действия, которые используются в качестве исходных полей, не поддерживаются в потоке.

Известные проблемы потоков

В перенесенных правилах имеется дополнительный символ @ для полей со строковым типом @

Если устаревший рабочий процесс правила автоматического создания записей настроен и содержит обычный текстовый символ @ в строковом поле, при миграции вы увидите два символа @ вместо одного. Например, если вы добавите адрес электронной почты в виде обычного текста в поле описания случая, то символ @ будет рассматриваться как специальный символ и будет перенесен как @@.

Это связано с тем, что @ идентифицируется как специальный символ для любого динамического выражения, например @triggerOutputs()?[body/_emailsender_value] в процессе миграции.

Решение — вручную удалить лишний знак @ в перенесенном потоке.

Миграция не поддерживает несколько элементов или условий с одинаковым значением "применимо, когда" в рамках одного соглашения SLA

В веб-клиенте несколько элементов могут быть определены с одним и тем же условием "применимо, когда" и разными критериями успеха для SLA. Однако эта возможность не поддерживается в едином интерфейсе. Следовательно, во время миграции никакой последующий элемент SLA этого типа с таким же условием "применимо, когда" не будет создан.

На следующих снимках экрана показан сценарий, который не поддерживается в едином интерфейсе. Два показанных условия "Применимо, когда" с разными критериями успеха.

Проблемы с атрибутами типа субъекта действий во время преобразования бизнес-процесса в поток

Атрибут типа субъекта действия, назначенный другому полю типа субъекта действия, не будет переноситься во время преобразования рабочего процесса в поток, так как в настоящее время Power Automate не поддерживает этот сценарий. (Наиболее часто затрагиваются поля Кому, От кого, Копия и Скрытая копия в электронных письмах). Несмотря на то, что миграция правила не завершится неудачей, значение данных для таких полей типа субъекта действия, которые зависят от другого атрибута типа субъекта действия, после миграции будет пустым.

Пример: атрибуты типа субъекта действия

Представление веб-клиента перед миграцией

Условные обозначения:

a. Поле От кого является полем типа субъекта действия, которому назначен другой атрибут типа субъекта действия {Bcc(Email)}. После миграции оно будет пустым.

b. Поле Кому будет перенесено.

Представление единого интерфейса после миграции

Условные обозначения:

b. Поле Кому.

Проверки "Первый не NULL" в выражениях в устаревшем рабочем процессе во время преобразования рабочего процесса в поток не поддерживаются

В устаревших рабочих процессах поле подстановки может быть сопоставлено с несколькими выражениями, в которых вы проверяете и назначаете выражение "Первый не NULL", как показано в примере веб-клиента ниже. В настоящее время это не поддерживается как часть преобразования рабочего процесса в поток, так как это известное ограничение устаревшего конструктора рабочего процесса. Поэтому преобразователь рабочего процесса назначает первое выражение без выполнения проверки на значение NULL. Затем он удаляет все оставшиеся выражения, независимо от того, имеют ли они значения, отличные от NULL. На приведенном ниже примере поток будет иметь только Regarding(Email) в поле Клиент на этом шаге.

Пример: выражения "Первый не NULL"

Представление перед миграцией

Условные обозначения:

a.Представление веб-клиента: в рабочем процессе в поле Клиент будет значение: {Regarding(Email); Contact(Create (Case)); Customer(Create (Case))}.

В едином интерфейсе в поле Клиент будет только: Regarding(Email) независимо от того, имеет ли он значение NULL.

Внимание

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

См. также

Вопросы и ответы о современном автоматическом создании записей

Перенос правил автоматического создания записей и соглашений SLA

Dynamics 365 SLA и сборник схем переноса ARC