Как отследить время назначения лида с помощью плагина в Dynamics 365

В современном процессе работы с лидами важно не только получать заявки, но и понимать, насколько быстро они перераспределяются на ответственных сотрудников. Одной из ключевых метрик в этом процессе является время от создания лида до его назначения менеджеру. В этой статье мы покажем, как с помощью кастомного плагина в Dynamics 365 CRM автоматически подсчитывать это время.

А узнать больше про это решение можно в нашем видео:

Цель плагина

Целью плагина является автоматический подсчёт количества минут от момента создания лида до его назначения реальному пользователю. Это позволяет:

анализировать эффективность логики назначения;

выявлять узкие места в автоматизации;

получать объективные метрики по скорости обработки заявок.

Создание кастомного поля в таблице лидов

Первым шагом создаём новое поле в таблице Lead через интерфейс Make Power Apps:

• Тип поля: Integer

• Формат: Duration

• Название: Assignment Duration

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

Настройка проекта в Visual Studio для плагина

Создаём новый проект в Visual Studio:

• Тип проекта: Class Library (.NET Framework)

• Название: LeadAssignmentDuration

• Целевая версия .NET: 4.6.2 (обязательно для CRM-плагинов)

После создания проекта устанавливаем NuGet-пакет Microsoft.CrmSdk.CoreAssemblies.

Подключение SDK и базовая структура класса плагина

Добавляем пространства имён:

using Microsoft.Xrm.Sdk;

using Microsoft.Xrm.Sdk.Query;

Класс реализует интерфейс IPlugin, а основной метод Execute будет содержать логику плагина. Также создаём перечисление для AccessMode, чтобы не использовать "магические числа" в коде.

Имплементация метода Execute и инициализация сервисов

Внутри метода Execute:

• инициализируем IPluginExecutionContext из IServiceProvider;

• получаем IOrganizationServiceFactory и IOrganizationService;

• реализуем try-catch блок для корректной обработки ошибок;

• добавляем перечисление AccessMode с флагом NonInteractive = 4.

Проверки конфигурации плагина и условий выполнения

Добавляем защитные проверки:

• плагин должен вызываться на Update;

• сущность должна быть lead;

• поле, на которое подписан плагин — ownerid;

• Target должен быть Entity;

• Pre-Image должен быть зарегистрирован.

  
  

Эти проверки предотвращают ошибки при некорректной регистрации шага плагина.

Работа с Pre-Image и извлечение нужных данных

Из Pre-Image извлекаем:

• предыдущего владельца (OwnerID);

• дату создания (CreatedOn).

  
  

Если эти значения отсутствуют — плагин прерывает выполнение.

Получение данных о владельцах и сравнение

Пишем вспомогательный метод GetOwnersById, который получает данные о двух пользователях (старом и новом владельцах) через QueryExpression.

Извлекаем поля:

• accessmode (тип доступа);

• applicationid.

  
  

Сравниваем владельцев по ID, чтобы избежать ложных срабатываний при повторном присвоении одного и того же пользователя.

Определение Application User и расчёт времени

Проверяем, был ли предыдущий владелец — Application User, а новый владелец — обычный пользователь с правами Read/Write.

Если да, то:

• получаем DateTime.UtcNow — момент reassignment;

• получаем дату создания из Pre-Image;

• вычисляем разницу во времени в минутах;

• округляем результат до целого числа.

Запись результата и регистрация плагина в CRM

Записываем полученное значение в ранее созданное поле Assignment Duration с помощью Target["new_assignmentduration"] = minutes.

Сборку плагина:

1. Подписываем (snk-файл).

2. Делаем Rebuild.

3. Регистрируем через Plugin Registration Tool:

   • В типе шага: Update на таблице Lead.

   • Filtering Attribute: ownerid.

   • Stage: Pre-Operation.

4. Регистрируем Pre-Image с полями createdon и ownerid.

Тестирование логики и отладка ошибок

Создаём тестовый лид с Owner = Application User. Затем переассайним его на реального пользователя. Если всё отработано корректно, поле Assignment Duration будет заполнено.

Если нет — перепроверяем:

• конфигурацию плагина;

• корректность pre-image;

• логику сравнения пользователей;

• правильность фильтрующих атрибутов.

Заключение

С помощью кастомного плагина мы автоматизировали важную метрику — время от создания лида до его назначения. Такая логика позволяет не только отслеживать производительность отдела продаж, но и глубже анализировать работу системы распределения. Внедрение подобных решений делает CRM более прозрачной и ориентированной на улучшение бизнес-процессов.