Битрикс24

Обогащение лидов между порталами Битрикс24 на бизнес-процессах

Обогащение лидов между порталами Битрикс24 на бизнес-процессах

Задача

У клиента несколько порталов Битрикс24. Лиды приходят из разных источников и в разные годы, и одна и та же компания может существовать в нескольких порталах, каждый раз с разным набором контактов. Менеджеры вручную копировали телефоны и почту из одного портала в другой. Это долго, часть данных терялась, а в карточках копились дубли.

Что нужно было:

  • находить совпадающие лиды в других порталах по ИНН компании;
  • переносить найденные телефоны, email и сайты в текущую карточку;
  • не плодить дубли и сохранять историю изменений;
  • не держать промежуточный сервер, который надо администрировать и защищать.

Решение

Логика реализована в виде трёх связанных бизнес-процессов Битрикс24:

  1. Маршрутизатор (запускается на лиде). Проверяет, не запускался ли процесс раньше, смотрит источник лида и год. По этому признаку выбирает, в какой портал идти за данными.
  2. Сборщик контактов. Делает пакетный запрос (batch) к нужному порталу, фильтрует лиды по совпадению и вытаскивает из них телефоны, почту и сайты.
  3. Слияние. Сравнивает найденные контакты с уже имеющимися в карточке, добавляет только новые и ставит найденный контакт первым в списке. Затем записывает в комментарий лида, что было исходно и что добавлено.

Внешнего сервера нет. Все вызовы идут напрямую между порталами по REST API через входящие вебхуки. Запуск интерфейса тоже размещён в облачном Битрикс24.
Подробнее о том, как мы связываем сервисы между собой, — на странице Разработка и автоматизация.

Как это работает

1. Маршрутизация по источнику и году. Процесс смотрит на источник и год лида. Лиды разных годов ищутся в разных порталах, где лежат их исторические данные. Для каждого варианта в процессе есть своя ветка, а в журнал пишется, куда ушёл запрос.

2. Защита от повторного запуска. Перед работой процесс проверяет поле «Уже запускался?». Если ответ да, он не перезапускает поиск. Так не возникает бесконечных циклов и повторных списаний.

3. Сбор и фильтрация. Для каждого контакта из карточки (телефон, email, сайт) запускается отдельная проверка. Итератор перебирает все значения поля, и для каждого выполняется свой поиск в другом портале. Чтобы не тянуть лишние данные, в запрос добавлен SELECT[0]=ID: забираем только идентификатор, а не всю карточку.

4. Слияние без дублей. Каждое найденное значение сравнивается с текущими. Если такой телефон или email уже есть, он пропускается. Если нет, добавляется. Найденный контакт ставится первым, остальные остаются после него. Итог записывается одним пакетом.

5. Аудит. В комментарий лида пишется, какие данные были в карточке до обработки и какие добавлены из других порталов. Менеджер и руководитель видят, откуда взялся каждый контакт.

Технические нюансы, которые пришлось решить

  • Двойное декодирование в batch. Телефон с «+» через вебхук и вложенный пакетный запрос теряет плюс. Мы кодируем значения дважды (urlencode), а амперсанд в параметрах передаём как %26. Без этого номера ломались.
  • Лишние данные. Пакетный запрос без ограничений возвращает огромные ответы. Ограничение полей через SELECT и флаг halt заметно сокращают объём и время работы.
  • Идемпотентность. Флаг «Уже запускался?» защищает от повторного выполнения, которое могло бы задвоить контакты.
  • Журнал. Каждый шаг пишется в журнал через LogActivity. Если что-то пошло не так, диагностика занимает минуты, а не часы.

Подробный разбор того, как собирается такой вебхук, — в статье Как собрать вебхук внутри бизнес-процесса Битрикс24

Результаты

  • Ручной перенос контактов между порталами заменён автоматическим процессом.
  • Дубли в карточках сведены к минимуму за счёт сравнения перед записью.
  • Нет внешнего сервера: не нужны VPS, поддержка, обновления и отдельная защита периметра.
  • Каждое изменение в карточке объяснимо: есть запись в комментарии.

Что это даёт бизнесу

Если у вас несколько порталов Битрикс24 или CRM-данные разбросаны по разным системам, мы можем построить похожую схему: с нуля или на основе уже существующих процессов, только средствами Битрикс24, без лишней инфраструктуры. Подробнее — на страницах Разработка и автоматизация и внедрение Битрикс24. Ещё один пример работы с бизнес-процессами — рассылка по часовым поясам клиентов.

Читать далее

Рассылка в Битрикс24 с учётом часовых поясов

Рассылка в Битрикс24 с учётом часовых поясов

Статья

Как мы научили бизнес-процесс облачного Битрикс24 отправлять тысячу писем так, чтобы каждый клиент получил своё в рабочее время по своему часовому поясу, не в выходной и не одновременно со всеми.

Читать
Не все письма сразу: 7 способов распределить рассылку в Битрикс24 по времени и ящикам

Не все письма сразу: 7 способов распределить рассылку в Битрикс24 по времени и ящикам

Статья

Когда бизнес-процесс запускается на сотнях лидов разом, письма уходят одним залпом и с одного адреса. Разбираем семь способов распределить отправку по времени и почтовым ящикам: как устроен каждый, где он ломается и когда его выбирать.

Читать
Как собрать вебхук внутри бизнес-процесса Битрикс24 без внешнего сервера

Как собрать вебхук внутри бизнес-процесса Битрикс24 без внешнего сервера

Статья

Связать два портала Битрикс24 можно без отдельного сервера: бизнес-процесс сам отправляет REST-запросы, получает ответы и обновляет карточки. Разбираем, как собрать такой вебхук, почему внутри batch значения кодируются дважды и где всё ломается.

Читать