Клиент говорит, что одно и то же обращение дважды попало не в ту команду. Правило маршрутизации выглядит верно, представители доступны, но никто не может показать, на каком этапе решение изменилось. Именно в такой момент нужен журнал маршрута.
Если команда раньше полагалась на диагностику единой маршрутизации Dynamics 365, не пытайтесь воссоздать старый экран снимками и ручными заметками. Microsoft сообщает, что функцию удалили 31 марта 2026 года, и рекомендует диагностику разговоров в Azure Application Insights. Практическая замена проста: подключить путь доказательств, провести известный тестовый разговор, отдельно проверить маршрутизацию и назначение и закрепить владельца журналов.
Начните с вопроса к журналу
Не начинайте с экспорта всех возможных событий. Сформулируйте один операционный вопрос. Почему разговор попал не в ту очередь? Почему работа не была предложена ни одному представителю? Почему не сработала передача? Почему изменение емкости повлияло на назначение?
- 1Опишите ожидаемый путьЗапишите канал, очередь, навык, приоритет, состояние представителя и владельца.
- 2Подключите доказательстваСвяжите управляемую среду, Application Insights, владельцев доступа и хранение.
- 3Проведите известный тестИспользуйте разрешенные идентификаторы и контролируемый разговор с реальной проблемой.
- 4Разделите маршрут и назначениеСначала подтвердите очередь, затем подходящих людей, емкость, предложение и владельца.
- 5Измените и повторитеИсправьте минимальную настройку и сравните новую квитанцию с исходной.
Запишите вопрос рядом со стабильной тестовой записью и временным окном. Сохраните канал, очередь, требуемый навык, приоритет, ожидаемое состояние представителя и ожидаемый результат. Такая база делает данные понятными и связывает техническую проверку с существующим аудитом правил маршрутизации, а не создает отдельный проект наблюдения.
Официальное уведомление Microsoft четко определяет границу продукта. Диагностика единой маршрутизации больше не является поддерживаемым инструментом. Ее заменяет диагностика разговоров в Application Insights. Значит, проверка должна доказать, что реальный рабочий элемент прошел по ожидаемому пути, а данные для объяснения решения появились вместе с ним.
Подключите путь доказательств
В инструкции по настройке среда Customer Service подключается к экземпляру Azure Application Insights через экспорт данных. Среда должна быть управляемой. Настройщику нужен подходящий доступ к Azure, а пользователю запросов как минимум чтение. Для одной среды доступна только одна конфигурация экспорта Customer Service в Application Insights.
Это не просто список настроек, а схема ответственности. Назначьте администратора Dynamics, владельца Azure, читателя трассировок и руководителя операций, который принимает результат. Определите, какая среда отправляет данные в какой ресурс Application Insights.
За прием данных взимается плата, поэтому оцените объем и срок хранения заранее. Доступ должен быть уже, чем членство в команде поддержки. Диагностика может раскрывать идентификаторы клиентов, действия сотрудников, названия очередей, изменения доступности и операционную структуру. Применяйте те же меры безопасности, что и к истории клиентов и аналитике сотрудников.
Проведите один известный разговор
Выберите тест, похожий на реальную проблему, но без конфиденциального содержания. Задайте известный канал, очередь, навык, приоритет, состояние представителя и ожидаемого владельца. Запишите время начала и разрешенные политикой идентификаторы, затем отправьте рабочий элемент обычным путем.
Не меняйте несколько правил во время теста. Контролируемый пример позволяет сравнить ожидание с доказательством. Если причиной может быть доступность, сверьте состояние с аудитом доступности представителей. Если возможна проблема профиля емкости, используйте руководство по безопасной настройке емкости.
Для каждого теста создавайте короткую квитанцию доказательств.
| Точка проверки | Владелец | Что записать | Когда остановиться |
|---|---|---|---|
| Вход теста | Руководитель операций | Канал, очередь, навык, приоритет и ожидаемый владелец | Ожидаемый путь неясен |
| Экспорт | Администратор Dynamics | Среда и ресурс Application Insights | Нельзя доказать назначение данных |
| Поиск трассировки | Читатель Azure | Временное окно и разрешенные идентификаторы | Тест нельзя изолировать |
| Маршрутизация | Владелец маршрутов | Решение об очереди и версия правила | Очередь изменилась без объяснения |
| Назначение | Владелец рабочей нагрузки | Доступность, емкость, предложение и принятие | Нельзя восстановить владельца |
| Приемка | Владелец сервиса | Исправление, повторный тест и мониторинг | Результат никто не принял |
Читайте маршрут и назначение отдельно
Разговор может попасть в правильную очередь, но к неправильному человеку. Бывает и наоборот: ошибка возникает до начала назначения. Не объединяйте эти вопросы.
Сначала проследите прием, классификацию и выбор очереди. Сравните фактические атрибуты с версией правил, активной в тот момент. Затем проверьте назначение: подходящих представителей, навыки, присутствие, емкость, предложения, отказ или тайм-аут и итогового владельца. Руководство по отказам и тайм-аутам объясняет, почему событие предложения еще не означает владение разговором.
Не додумывайте отсутствующие данные. Пустой результат может означать ошибку экспорта, неверное временное окно, недостаточный доступ или то, что рабочий элемент не вошел в ожидаемую среду. Докажите путь вторым известным тестом до изменения маршрутизации в производстве.
Общий клиентский инбокс показывает текущего владельца и историю разговора операционной команде, но не заменяет телеметрию платформы. Инбокс нужен для понимания влияния на клиента, а диагностика для объяснения системного решения.
Измените одно и повторите тест
Если данные указывают на правило, навык, членство в очереди, присутствие или емкость, измените минимально необходимый элемент. Запишите утверждающего и способ отката. Повторите тот же тест с тем же ожидаемым путем.
Сравните две квитанции. Исправленный тест должен попасть в нужную очередь и к нужному владельцу, а журнал должен объяснять причину. Если успех появился только после ручного вмешательства руководителя, проблема не исправлена. Такое вмешательство тоже является доказательством, но его следует отметить как исключение.
После запуска регулярно проверяйте неназначенную работу, повторные тайм-ауты, неожиданные смены очереди и необъяснимые ручные назначения. Сигнал должен вести к владельцу и решению, а не к еще одному шумному инбоксу.
Завершайте старый путь осторожно
Уведомление Microsoft ведет к отдельной процедуре удаления старых диагностических данных маршрутизации из Dataverse. Не удаляйте историю только потому, что функция исчезла. Соблюдайте политику хранения, сохраните доказательства для действующих расследований, подтвердите приемку Application Insights и запишите, что и кем удалено.
Цель не в вечном хранении каждого события. Один маршрут должен быть объясним от запроса клиента до окончательного владельца. Используйте этот стандарт после изменения правила, профиля емкости или процесса. При более широком пересмотре ответственности свяжите доказательства с операционной моделью поддержки.
Часто задаваемые вопросы
Доступна ли диагностика единой маршрутизации Dynamics 365
Microsoft сообщает, что функция удалена 31 марта 2026 года. Поддерживаемый путь теперь проходит через диагностику разговоров в Azure Application Insights.
Исправляет ли диагностика маршрутизацию автоматически
Нет. Она записывает события жизненного цикла. Администратор или владелец операций должен интерпретировать трассировку, внести контролируемое изменение и повторить тест.
Какой тест провести первым
Начните с недавней повторяемой проблемы, для которой известны ожидаемые очередь и владелец. Не делайте широкое изменение в производстве, пока не можете изолировать тест и объяснить маршрутизацию и назначение.
Помочь применить это руководство?Спросить команду DripTell
От чтения к действию
Нужна помощь с применением этого подхода в вашей компании?
Оставьте контакты. Мы учтём материал, который вы читаете, и начнём с полезного ответа для вашей команды.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники
