Поділитися через

Поширені запитання щодо засобу перенесення

  • Стаття

Інструмент міграції для автоматичного створення записів правил та угод про рівень обслуговування (SLA)

Хто може мати доступ до засобу перенесення або виконувати його?

Адміністратори та користувачі, які мають ролі менеджера CSR, можуть запускати інструмент міграції.

Чи перенесені правила автоматично активуються після перенесення?

Ні. Перенесені правила потрібно активувати вручну після завершення міграції.

Чи можна використовувати застарілі правила після настання дати їх вилучення?

Так. Активні застарілі правила продовжують діяти після кінцевого терміну відмови, доки їх не буде деактивовано. Однак досвід редагування та можливість підтримки припиняються після вилучення.

Чи можна активувати правило зі статусом "незавершена" міграція?

Ні. Перенесене правило активується лише тоді, коли ви переключите перемикач Позначити як завершене на Так після перегляду неповного правила та виправите всі наявні проблеми. Саме тоді правило вважається успішно перенесеним.

Чи деактивується застаріле правило після перенесення?

  • Для автоматичного створення записів – так. Коли ви активуєте перенесене правило автоматичного створення запису в єдиному інтерфейсі, відповідне застаріле правило деактивується.
  • Для угод про рівень обслуговування – ні. Коли ви активуєте перенесене правило SLA в єдиному інтерфейсі, відповідне застаріле правило залишається активним, оскільки ці два правила можуть співіснувати.

Що означає статус «незавершена» міграція?

  • У розділі Підсумок: Загальний процес міграції не зміг успішно завершити міграцію всіх вибраних правил.
  • Поруч із правилом: Або правило не вдалося виконати, або правило не вдалося повністю перенести (тобто, один або кілька елементів або умов не вдалося перенести).

Де можна знайти список частково перенесених правил, що відстежуються в засобі перенесення?

Правила, які частково перенесено або визначено як неповністю перенесені, не вважаються повністю перенесеними. Тому вони відстежуються в розділі «Очікування » в розділі «Підсумок ». Під Migrated враховуються лише правила, які успішно завершили міграцію.

Чи підтримує інструмент міграції користувацькі форми або поля?

  • Для автоматичного створення записів – так. Інструмент міграції підтримує користувацькі сутності, поля, атрибути та конфігурації.
  • Для угод про рівень обслуговування – ні. Інструмент міграції не повністю підтримує користувацькі сутності, поля, атрибути та конфігурації. Щоб завершити міграцію, користувачі повинні змінити всі існуючі потоки налаштування, робочі процеси, плагіни або інший користувацький код для користувацьких сутностей, полів, атрибутів і конфігурацій.

Чи потрібна мені окрема ліцензія перед Power Automate міграцією?

Ні. Щоб отримати додаткові відомості про правила ліцензування, перейдіть до розділу Які існують Microsoft Power Apps і Power Automate використовуються права для програм Dynamics 365?

Деякі з моїх правил неповні або частково перенесені. Що потрібно зробити?

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

Чи можна повторно виконати засіб перенесення для певного перенесеного правила?

Так, ви можете повторно запустити інструмент міграції для певного перенесеного правила на основі таких критеріїв:

  • Для неповних правил або правил, які не вдалося перенести: Виберіть те саме правило під час повторного запуску інструмента міграції. Засіб автоматично замінює наявне неповне або невдале правило новим перенесеним правилом.
  • Для успішно перенесених правил: Видаліть перенесене правило в єдиному інтерфейсі, перш ніж повторно запускати інструмент міграції.

Що станеться після завершення міграції з наявними записами SLA, пов’язаними із застарілими угодами SLA?

  • Якщо застарілий SLA деактивовано після міграції: Таймер продовжить працювати до стану терміналу для таких записів SLA. Однак функція «Рішучість» і «Пауза » не працюватиме.
  • Якщо застарілий SLA все ще перебуває в активному стані: наявні записи SLA, пов’язані з застарілими угодами SLA, продовжуватимуть працювати належним чином.
  • Якщо ви хочете використовувати SLA, створені в програмах єдиного інтерфейсу, для наявних записів: Вам доведеться вручну оновити поле SLA до єдиного інтерфейсу SLA або написати плагін для оновлення записів. Наприклад, логіка плагіна може бути Modern Flow або Workflow.

Щоб отримати інформацію про перенесені правила або потоки в сучасному автоматичному створенні записів, перейдіть до розділу FAQ про сучасне автоматичне створення записів.

Відомі проблеми з перетворенням умов

У цьому розділі описано ключові сценарії, коли правила або елементи не можуть успішно завершити перенесення.

Ні. Наразі ми підтримуємо лише один рівень ієрархії пов’язаних сутностей. Такі елементи правил або умови можуть бути успішно перенесені лише в тому випадку, якщо ви видалите будь-яку пов’язану сутність у груповому реченні перед міграцією. Якщо ви не вживете жодних заходів, правило не спрацює під час передміграційного оглядукрок . Якщо ви вирішите продовжити перенесення, правило матиме порожню умову для пов’язаного елемента.

Перегляд веб-клієнта перед міграцією

Знімок екрана передміграційного веб-клієнта елемента з пов’язаними сутностями у вкладеному груповому реченні.

Легенда:

a. Назва пункту.

Перегляд єдиного інтерфейсу після міграції

Знімок екрана перегляду єдиного інтерфейсу після міграції елемента з пов’язаними сутностями у вкладеному груповому реченні.

Легенда:

2a. «_FailedMigration» додається до назви переміченого елемента.

2b. Той самий стандартний заповнювач,Created On Equals 2200-01-01, додається до умови.

Чому елементи або умови мого правила з полем DateType, яке використовує оператора Not-On-On, не виконуються під час передміграційної перевірки та фактичної міграції?

Оператор «Не ввімкнено » для типу даних «Дата » не підтримується в єдиному інтерфейсі. Тому він не підтримується в рамках міграції. Щоб вирішити цю проблему, ви можете змінити застарілі елементи або умови з {не вибраної дати} на {вибрану дату менше ніж і вибрану дату більше, ніж} у веб-клієнті, перш ніж повторно запустити інструмент міграції для відповідного правила.

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

Перегляд веб-клієнта перед міграцією

Знімок екрана передміграційного веб-клієнта елемента з оператором Not-On для поля DateType.

Легенда:

a. Назва пункту.

Перегляд єдиного інтерфейсу після міграції

Скріншот вигляду єдиного інтерфейсу після міграції елемента з оператором невключення для поля DateType.

Легенда:

2a. «_FailedMigration» додається до назви переміченого елемента.

2b. Умова Created On Equals 2200-01-01 додається до умови.

Чому під час перенесення було змінено дані в полі "Дата й час"?

Окремого поля часу в єдиному інтерфейсі не існує. Таким чином, поле «Дата-час » зміниться з елемента керування календарем на текстове поле. Вхідні дані повинні бути в певному форматі, як показано в текстовому полі в наступному прикладі.

Приклад: поле «Дата-час»

Перегляд веб-клієнта перед міграцією

Знімок екрана передміграційного веб-клієнта, де поля DateTime представлені елементами керування календаря.

Легенда:

a. Поле «Дата й час » перед міграцією .

б. Поле «Лише дата передміграції ».

Перегляд єдиного інтерфейсу після міграції

Знімок екрана подання єдиного інтерфейсу після міграції, де поля DateTime представлені текстовими полями.

Легенда:

a. Поле дати й часу після міграції .

б. Поле "Лише дата після міграції ".

Чому після міграції деякі поля оператора порожні в єдиному інтерфейсі?

Для типів даних пошуку в єдиному інтерфейсі та інструменті міграції підтримуються лише оператори equal, not equal, null та not null . Оператори under і not-under не підтримуються в єдиному інтерфейсі, а отже, вони не підтримуються в інструменті міграції. Будь-які умови, які мають оператори under або not-under , після міграції перекладаються як пов’язані сутності . Вони відображаються як порожні в єдиному інтерфейсі і не можуть бути відредаговані.

Приклад: поля оператора Under і not-under

Перегляд веб-клієнта перед міграцією

Скріншот перегляду веб-клієнта перед міграцією, де використовується умова під операторами.

Легенда:

грн.Під операторами.

Перегляд єдиного інтерфейсу після міграції

Знімок екрана вигляду єдиного інтерфейсу після міграції, де умова має порожнє поле оператора.

Легенда:

б. Порожнє поле оператора.

Нотатка

Наведені нижче обмеження застосовуються, коли в службі підтримки клієнтів Hub визначено умову:

  • Елемент керування «Вибір дати й часу» більше не доступний в умовах. Однак ви все одно можете редагувати дату й час у текстовому полі.
  • Підтримується лише один рівень ієрархії пов’язаних сутностей. Однак ви можете вибрати вкладені, пов’язані сутності в програмі.
  • Пов’язана сутність у групі речення та/або не підтримується.
  • Оператор Не ввімкнено для типу даних Дата не підтримується.
  • Для типу даних Lookups підтримуються лише оператори equal, not equal, null та not null . Оператори under і not-under не підтримуються.

Чи можна знову перенести правило після його активації?

  • Для правил автоматичного створення записів – так. Активоване правило можна перенести знову, але спочатку його потрібно деактивувати та видалити з єдиного інтерфейсу.
  • Для угод про рівень обслуговування – ні. Після активації перенесеного правила SLA воно зв’язується з іншою сутністю (наприклад, інцидентом) або використовується. За умовчанням активоване правило успішно перенесено. Перш ніж знову перенести активоване правило, його потрібно видалити. Однак існує обмеження для правил SLA єдиного інтерфейсу. Після того, як правило пов’язано з інцидентом або сутністю (тобто після його одноразової активації), його не можна видалити, навіть якщо його деактивовано. Тому правило не можна перенести знову, якщо воно було раніше активоване або застосоване.

Чи можна переносити застарілі стандартні правила SLA ?

Ні. Інструмент міграції підтримує лише розширені правила SLA. Стандартні правила SLA застаріли. Вони більше не підтримуються в єдиному інтерфейсі, а отже, не підтримуються в інструменті міграції. Додаткові відомості див. в розділі Стандарті угоди про рівень обслуговування в Dynamics 365 Customer Service застаріли.

Відомі проблеми

Застарілість властивості каналу

Якщо ви використовували будь-які властивості каналу для налаштування застарілих правил, інструмент перенесення цих правил не здійснить успішну міграцію. Не існує загального обхідного шляху, який можна застосувати для виправлення цієї прогалини для всіх користувачів. Обхідний шлях значною мірою залежить від того, як ви використовуєте властивості каналу в застарілих правилах.

Різниця в поведінці при виборі опції "Створювати кейси для дій, пов’язаних з вирішеним кейсом"

  • Застаріла поведінка: Якщо електронний лист має пов’язану справу, яка була вирішена з вказаного часу, вирішена справа повторно активується за замовчуванням. Кастомізація не потрібна.
  • Сучасна поведінка: Якщо електронний лист має пов’язаний інцидент, який було вирішено з вказаного часу, новий випадок створюється за замовчуванням. Налаштування потрібне для повторної активації існуючого інциденту замість створення нового.

Різниця в поведінці при виборі опції «Створити кейс, якщо для клієнта існує дійсне право»

  • Застаріла поведінка: Якщо відправник електронного листа не має дійсного права, а електронний лист має пов’язаний регістр, існуючий пов’язаний випадок оновлюється.
  • Сучасна поведінка: Якщо відправник електронної пошти не має дійсних прав, потік не викликається.

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

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

Відомі проблеми з циклами

Перенесені правила мають додатковий символ @ для полів із типом @ string

Якщо робочий процес застарілого автоматичного створення записів налаштовано та містить звичайний текстовий символ @ у рядковому полі, ви побачите два @ замість одного під час міграції. Наприклад, якщо ви додасте адресу електронної пошти у вигляді простого тексту в поле опису інциденту, то символ @ буде розглядатися як спеціальний символ і переноситися як @@.

Це пов’язано з тим, що @ визначається як спеціальний символ для будь-якого динамічного виразу, наприклад @triggerOutputs()?[ body/_emailsender_value] у міграційному потоці.

Обхідний шлях полягає в тому, щоб вручну видалити зайвий @ у перенесеному потоці.

Міграція не підтримує кілька елементів або умов з однаковим значенням "застосовується коли" в межах одного SLA

У веб-клієнті можна визначити кілька елементів, які мають однакову умову «застосовується, коли» та різні критерії успіху для SLA. Однак така ж можливість не підтримується в єдиному інтерфейсі. Тому під час міграції не створюються наступні елементи SLA цього типу, які мають ту саму умову "застосовується коли".

На наведених нижче знімках екрана показано сценарій, який не підтримується в єдиному інтерфейсі. Дві наведені умови «застосовується, коли» мають різні критерії успіху.

Знімок екрана з умовою

Скріншот тієї самої умови «застосовується, коли», яка має різні критерії успіху.

Проблеми з атрибутами типу партії активності під час перетворення робочого процесу в потік

Атрибут типу партії активності, призначений іншому полю типу партії активності, не буде перенесено під час перетворення робочого процесу в потік, оскільки Power Automate наразі він не підтримує цей сценарій. (Найбільш часто це стосується полів Кому, Від, CC та BCC у повідомленнях електронної пошти.) Хоча перенесення правила не вдасться здійснити, значення даних для полів типу такої активності, які покладаються на інший атрибут типу партії активності, після перенесення будуть порожніми.

Приклад: атрибути типу вечірки активності

Перегляд веб-клієнта перед міграцією

Знімок екрана подання веб-клієнта перед міграцією, де робочий процес має два атрибути типу активності: From і To.

Легенда:

a. Поле «Від» – це поле типу «Сторона активності», якому призначено інший атрибут типу «Активність» – { «Прихована копія (електронна пошта)}». Після міграції він буде порожнім.

б. Поле «Кому» буде перенесено.

Перегляд єдиного інтерфейсу після міграції

Знімок екрана вигляду єдиного інтерфейсу після міграції, куди було перенесено поле «Кому».

Легенда:

б.До поля.

Перевірки "First Not Null" у виразах у застарілих робочих процесах не підтримуються під час перетворення робочого процесу в потік

У застарілих робочих процесах поле підстановки може бути зіставлене з кількома виразами, де ви відзначаєте та призначаєте вираз «Спочатку не null», як показано в наведеному нижче прикладі веб-клієнта. Через відомі обмеження в успадкованому конструкторі робочих процесів цей підхід не підтримується під час перетворення робочого процесу в потік. Таким чином, перетворювач робочих процесів призначає перший вираз без виконання перевірки null. Потім він видаляє всі інші вирази, незалежно від того, чи мають вони ненульові значення. У наведеному нижче прикладі ланцюжок матиме лише Regarding(Email) у полі Customer на цьому кроці.

Приклад: вирази "First Not Null"

Передміграційний режим

Знімок екрана перегляду веб-клієнта для поля Щодо.

Легенда:

грн.Перегляд веб-клієнта: У робочому процесі поле Customer має {Regarding (Email); Контакт(створити (кейс)); Замовник(створити (кейс)).}

У єдиному інтерфейсі у полі Customer є лише Regarding(Email), незалежно від того, чи є воно null.

Важливо

Якщо проблеми з інструментом міграції не зникають, зверніться до адміністратора або служби підтримки Microsoft.

Див. також

Поширені запитання про сучасне автоматичне створення записів

Перенесення правил автоматичного створення та оновлення записів і SLA

План дій щодо перенесення ARC та Dynamics 365 SLA