Кастомный Consent Center для Dynamics 365

В стандартной экосистеме Microsoft для управления согласиями клиентов существует мощный инструмент — модуль Dynamics Marketing (Customer Insights – Journeys) со встроенным Consent Center. Однако приобретение полноценной лицензии только ради этого функционала экономически нецелесообразно. Именно с такой ситуацией столкнулись мы при работе с одним из наших клиентов: потребность в интеграции с внешними сервисами коммуникации — в частности, с Twilio — была реальной, а возможности стандартного решения оказались избыточными и дорогостоящими. В результате мы разработали кастомный, лёгкий и отказоустойчивый модуль управления согласиями, который полностью закрыл потребности клиента и дал удобный интерфейс для работы с системой.

В этой статье расскажем о реальном кейсе создания собственного lightweight Consent Center для Dynamics 365, кастомного PCF Control и архитектуры управления подписками и отписками клиентов.

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

https://www.youtube.com/watch?v=0xeqMAZfh3w

Контекст и предпосылки

Клиент использует таблицу Contact, которую внутри называет «лиды». Стандартные поля Dynamics — do not email, do not phone call — не покрывали все сценарии: они неудобны, и, что важнее, у клиента в системе присутствовало большое количество дублей. Один и тот же лид мог существовать в нескольких копиях, поэтому простое обновление флага do not email не давало стопроцентного результата. Дополнительным требованием было наличие аудита: система должна фиксировать, кто, когда и по какому каналу изменил статус подписки.

Архитектура данных: контакт-поинты

Для управляемости решения мы ввели восемь точек взаимодействия — контакт-поинтов. Изначально их было четыре, однако в процессе прототипирования клиент уточнил требования, и список расширился:

• All Emails — стандартное поле do not email; при активации полностью блокирует все письма на уровне системы.

• Marketing Email — стандартное поле do not bulk emails; блокирует массовые рассылки на уровне CRM.

• Marker Email — кастомное поле для транзакционных писем, отправляемых через автоматизации; проверяется непосредственно в логике автоматизации.

• Phone Call — стандартное поле.

• SMS — кастомное поле, на которое реагируют внешние системы, в том числе Twilio.

• Alternate Phone и Alternate SMS — два кастомных поля для альтернативных номеров, поскольку у клиентов может быть несколько контактных телефонов.

Важный нюанс: если Marker Email разблокирован, но All Emails заблокирован на уровне системы — письмо создаётся и привязывается к лиду как запись, но фактически никуда не отправляется.

Модель данных: три кастомных таблицы

Для хранения истории и обеспечения аудита мы построили логику на трёх таблицах:

1. Unsubscribe — технический буфер-ресивер. Сюда поступают запросы на отписку в формате JSON из внешних сервисов, веб-форм или внутренней логики системы.

2. ConsentLog — историческая таблица событий. Каждая запись — это конкретное действие по конкретному контакт-поинту: направление (opt-in / opt-out), источник запроса, дата.

3. CustomerConsent — финально агрегированная таблица с уникальными контакт-поинтами. Именно здесь хранится актуальный текущий статус каждого контакт-поинта для каждого клиента, без дублей.

Логика автоматизации и пакетная обработка

Когда клиент отписывается — через веб-форму, через Twilio или вручную — в таблице Unsubscribe создаётся запись. Бэкенд-триггер парсит JSON и создаёт отдельные логи в ConsentLog по каждому контакт-поинту.

Вместо мгновенной обработки каждой транзакции мы реализовали пакетную обработку через WebJob: раз в час процесс собирает все новые логи, анализирует их в разрезе клиентов и контакт-поинтов и обновляет записи в CustomerConsent. Если запись существует и статус отличается — обновляет; если контакт-поинт не найден — создаёт. После этого WebJob находит все лиды по изменившимся контакт-поинтам и переключает соответствующие поля непосредственно на записи лида. Такой подход критически важен: при массовых импортах, где могут прилетать сотни тысяч записей, real-time обработка попросту положила бы асинхронные сервисы системы.

Отдельный канал — WebSubmission: при создании нового лида через веб-форму данные поступают не через таблицу Unsubscribe, а напрямую в ConsentLog, в обход буфера. Это отражает логику, при которой сама подача формы означает initial consent — статус opt-in по умолчанию.

Каналы управления статусом согласия

Архитектура предусматривает три способа изменить статус согласия:

1. Мануальная отписка — выполняется менеджером непосредственно в Dynamics через кастомный PCF Control на форме лида.

2. Веб-форма — клиент самостоятельно выбирает, от каких коммуникаций хочет отписаться или на какие подписаться.

3. API-запрос — из внешних систем, например Twilio.

PCF Control: интерфейс управления

Кастомный PCF Control встраивается на форму лида и полностью заменяет стандартные toggles. Он отображает:

• все текущие контакт-поинты лида с актуальным статусом и датой последнего изменения;

• пометку Initial Customer Consent (opt-in), если изменений ещё не было;

• пометку No Contact Point, если, например, alternate phone не указан;

• историю изменений с фильтрацией по контакт-поинту и направлению (opt-in / opt-out), с указанием источника события.
  

Важно: PCF Control не работает с лидом напрямую. При загрузке формы он считывает данные (email, основной телефон) и ищет соответствующие записи в таблице CustomerConsent по уникальному контакт-поинту.

При мануальной отписке менеджер создаёт событие AddConsentEvent, указывает метод связи (email, телефонный звонок, личный визит) и меняет статус. Предусмотрена и логика скрытия: если All Emails переводится в opt-out, контакт-поинты Marketing Email и Marker Email скрываются, но их собственный статус не меняется — он сохраняется до момента, пока All Emails не будет снова разблокирован. После подтверждения изменений пользователь получает уведомление о запуске автоматизации с завершением в течение часа, а в PCF отображается, какие именно изменения ожидают обработки.

Заключение

Разработанный кастомный модуль управления согласиями решил сразу несколько задач. Во-первых, он позволил сократить затраты на лицензирование: покупать Customer Insights – Journeys исключительно ради Consent Center экономически неоправданно. Во-вторых, архитектура на основе таблицы логов обеспечила полный аудит изменений: теперь всегда известно, кто, когда и по какому каналу изменил статус подписки. В-третьих, пакетная обработка через WebJob устранила риски при массовых импортах данных и обеспечила стабильность работы системы под нагрузкой.

Получившееся решение — лёгкое, гибкое и полностью отвечающее потребностям интеграции с внешними сервисами — наглядно демонстрирует, что кастомная разработка на базе Dataverse и PCF Framework может быть не просто заменой «из коробки», но и превосходить её по удобству и управляемости.