От заказчика получено задание: нужно в сервис по прозвону отправлять заявки через API, после чего сервис будет по API возвращать результат.
Отправлять данные хуком на сервис достаточно просто и для нас безопасно.
А вот обратно, если дадим вебхук от Битрикс24, то получаем дыру в безопасности размером с вселенную.
Какие есть варианты?
- Написать промежуточный скрип. Но тут те же яйки, только в профиль. Хук с опасными правами будем хранить на своей стороне. Отказ.
- Сделать CRM-форму в Б24, на которую по API с сервиса будет идти отправка данных. Достаточно номера телефона, в настройках формы будем объединять дубликаты. А на нужную стадию поставим триггер на заполнение формы. Выполняем.
Выполнил настройку, проектировали на лиде с уникальным номером в рабочем статусе - всё отрабатывает как и задумано.
Перешли к тестам на неуникальных номерах (дубли) - стал перемещать случайные лиды, не тот лид по которому был звонок, а любой другой с тем же номером.
Потренировали на браке - полное фиаско, лид как был в браке так и остаётся, а в CRM создаётся новый лид.
Что делать? Писать обработчик… и тут вспомнил идею Максима Белого про использование смарт-процесса, как прокладки между CRM и внешним сервисом.
Создал СП «Перемещатель» вида Список с включенными бизнес-процессами и с одним дополнительным полем «Тип действия» типом Строка (чтобы было проще)
Вообще частая история, когда в начале приходит одно ТЗ «Все успешные будем перемещать в точку Х», а через неделю апгрейд «Неуспешные в Y», и ещё через два дня «Хорошо бы Y делить на Z и G и… по тем что в Х ставить задачу».
В название СП будем предавать ID лида, в поле «Тип действия» W - для успешных, L - для брака и что ещё душе угодно для других статусов.
Далее используем БП срабатывающий на создание.
Который будет запускать БП на лиде.
Тестим, работает. Перекрестим - пусть приносит деньги заказчику, а мне очередная статуэтка «Костыль недели».
