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

Інструмент міграції для автоматичних правил створення записів та угод про рівень обслуговування (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, яке використовує оператор «Не ввімкнено», не виконуються під час передміграційної перевірки та фактичної міграції?

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

Приклад: поле DateType, яке використовує оператор Non-On (Не ввімкнено)

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

Легенда:

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

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

Легенда:

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

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

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

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

Приклад: поле DateTime

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

Легенда:

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

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

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

Легенда:

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

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

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

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

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

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

Легенда:

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

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

Легенда:

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

Нотатка

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

• Елемент керування вибором дати й часу більше не доступний в умовах. Однак ви все одно можете редагувати дату й час у текстовому полі.
• Підтримується лише один рівень ієрархії пов’язаних сутностей. Однак ви можете вибрати вкладені, пов’язані сутності в програмі.
• Пов’язана сутність у групі речення та/або не підтримується.
• Оператор Не ввімкнено для типу даних Дата не підтримується.
• Для типу даних 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» у повідомленнях електронної пошти.) Хоча перенесення правила не вдасться здійснити, після перенесення значення даних для полів типу "Сторона активності", які залежать від атрибута "Тип іншої сторони активності", буде порожнім.

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

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

Легенда:

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

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

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

Легенда:

б.До поля.

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

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

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

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

Легенда:

грн.Перегляд веб-клієнта: У робочому процесі в полі «Клієнт» {є «Щодо» (Електронна пошта); Контакт(Створити (Кейс)); Замовник(створити (кейс)).}

У єдиному інтерфейсі в полі «Клієнт» є лише «Стосується(Електронна пошта)», незалежно від того, чи є воно null.

Важливо

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

Пов’язані відомості

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

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

Dynamics 365 SLA та ARC Migration Playbook