Запуск процессов в CRM через вебхук: как внешняя система приводит CRM в движение

Вторник, 09:12. Платёжный провайдер ещё в 03:40 сообщил, что семь карт списать не удалось. Уведомление упало в общий почтовый ящик и осталось там лежать. Руководитель операционного отдела видит его только когда открывает почту. За эти пять с половиной часов ни одному из семи клиентов не позвонили, ни одной задачи не создали, двое уже успели закрыть свои аккаунты. Никто не ошибся: информация была, она просто не попала в CRM.

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

Входящий вебхук — это уведомление или команда?

Запрос от внешней системы — это утверждение о мире: «вот это произошло тогда-то». Не приказ. Различие звучит отвлечённо, но оно определяет всю конструкцию. Точка приёма, которая исполняет приказы, записывает в ваши данные каждую ошибку чужой системы: один запрос, случайно ушедший из тестового контура, — и реальный клиент получает реальное сообщение. Точка приёма, которая оценивает утверждения, сначала спрашивает: есть ли у нас такая запись, не в этом ли она уже состоянии, касается ли нас это событие вообще.

На практике это означает, что первый шаг процесса — не действие, а условие. Шаг «Условное ветвление» в конструкторе процессов работает именно здесь: одна ветка, если статус в теле запроса «ошибка списания», другая — если «возврат», и ни одной, если значение вам незнакомо, — тогда запуск тихо завершается. Условие в начале облегчает написание всего остального, а логику правил в целом мы разбирали в материале об автоматизации процессов условными правилами.

Вторая выгода проявится в день, когда провайдер изменит формат. Поле переименуют, добавят новое значение статуса, тело обернут ещё одним слоем. Процесс-исполнитель безупречно сделает не то. Процесс-оценщик не найдёт совпадения и остановится. Заметить остановившийся процесс несравнимо легче, чем тот, который две недели тихо делает неправильное.

Какие внешние события вообще заслуживают процесса?

Не каждое событие стоит автоматизации. Простой фильтр: изменится ли от него поведение человека? Если нет — это строка журнала, а не триггер. Списание не прошло, пробный период закончился, обращение открыли повторно, до продления договора тридцать дней — во всех случаях кто-то должен что-то сделать. А вот «пользователь сменил фото профиля» можно записать в карточку, но никого будить этим не нужно.

Второй фильтр — скорость обесценивания. Если ценность события испаряется за часы, нужен вебхук; если держится днями, хватит ночной синхронизации. Запись, созданная через сервис онлайн-брони, относится к первой группе: клиент может отменить её в ближайший час. Как выстроить этот путь целиком, мы показывали в статье про ссылку бронирования, из которой запись попадает прямо в CRM.

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

Вебхук, опрос по расписанию или ручной ввод?

Эти три способа не конкурируют, а закрывают разные задачи. Вебхук — когда чужая система сама сообщает вам. Опрос — когда вы спрашиваете с интервалом. Ручной ввод — для малых объёмов с расплывчатыми правилами. Критерии выбора между первыми двумя укладываются в короткую таблицу:

Критерий	Вебхук (событие приходит)	Опрос по расписанию
Задержка	Секунды	Не меньше интервала опроса
Потерянные события	Пропадают при сбое запроса, нужны повторы	Подхватываются на следующем круге
Нагрузка	Только когда событие есть	Каждый круг, даже вхолостую
Настройка	Адрес и секрет подписи на стороне отправителя	Авторизация, постраничность, метка последнего чтения
Где уместно	Единичные события с немедленной реакцией	Массовая сверка и итоги дня

Зрелые связки обычно используют оба: вебхук даёт скорость, ночной опрос служит страховкой и подбирает всё, что не дошло. Сравнение разных способов соединить инструменты между собой мы собрали в обзоре вариантов интеграции CRM через API и вебхуки.

Как разложить поля тела запроса по записям CRM?

Сопоставление полей — самая скучная и самая решающая часть настройки. Сначала идентичность: какое поле входящего тела соответствует вашей записи? Адрес почты удобен и хрупок: один и тот же человек может зарегистрироваться дважды с разными адресами. Если сохранить в карточке собственный идентификатор внешней системы и сверяться по нему, половина проблем, которые всплыли бы через полгода, исчезает сразу.

Дальше — преобразования. Сумма приходит в копейках или в рублях, в каком часовом поясе метка времени, статусы приходят в верхнем регистре? Ответы стоит записать до сборки, потому что каждое из этих расхождений умеет ломаться беззвучно. И отдельно решите, что делать с отсутствующим полем: процесс останавливается, если номер телефона не пришёл, или идёт дальше с пустым значением?

Наконец, держите сопоставление в одном месте. Если пять типов событий одного провайдера повторяют одно и то же преобразование в пяти разных процессах, переименование одного поля означает пять правок. Шаг «Вызов подпроцесса» позволяет собрать общие шаги сопоставления в один процесс и вызывать его из остальных; защита от циклов и от избыточной вложенности не даёт цепочке вызвать саму себя.

Как убедиться, что запрос пришёл именно от той системы?

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

Рядом с подписью стоят ещё две вещи: проверка метки времени и идентификатор события. Метка не даёт злоумышленнику повторно отправить перехваченный когда-то корректный запрос — всё, что вне узкого окна, отклоняется. Механику мы разбирали отдельно в материале про проверку подписи и защиту от повторной отправки.

Третий слой — права. Подпись говорит, кто прислал запрос, но не говорит, что ему позволено. Событие от платёжного провайдера, переводящее сделку на другой этап, выглядит разумно; то же событие, удаляющее пользователя, — нет. Ограничение возможностей процесса по источнику события сокращает ущерб, если секрет всё-таки утечёт.

Что должно происходить, когда событие приходит дважды?

Повтор — не поломка, а штатное поведение. Если провайдер не получил ваше подтверждение вовремя, он отправит запрос снова. Обрыв связи, перезапуск или замедление на вашей стороне приводят к тому, что одно и то же событие приходит дважды, иногда трижды. Процесс, который этого не учитывает, отправит клиенту одно сообщение дважды, откроет одинаковую задачу дважды и разделит одну сделку на две.

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

Эта проверка — обязательное условие для передачи рутины триггерам, иначе автоматизация потратит сэкономленное время на уборку. Что это значит на стороне задач, показано в материале о том, как снять рутину триггерами без кода: после второй задачи-дубля менеджер перестаёт доверять автоматизации и возвращается к ручной работе.

Кто разбирает ситуацию, если шаг упал посреди запуска?

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

«История запусков и повтор» хранит запись каждого прогона и позволяет перезапускать упавшие не по одному, а пакетом. После получасового сбоя у провайдера это разница между сорока запусками, открытыми вручную, и одним действием. Незавершённые прогоны тоже не копятся: механизм очистки зависших запусков находит и убирает их, и список истории остаётся местом, куда действительно можно заглянуть.

Повтор подходит не для каждой ошибки. Временный сетевой сбой стоит попробовать снова; «такого клиента нет в системе» повторами не лечится, здесь нужен человек. Порядок передачи второй группы людям описан в материале про эскалацию нужному человеку до нарушения SLA — та же логика без изменений работает и для технических сбоев.

Как отрепетировать процесс до публикации?

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

Для этого есть пробный прогон: он проходит процесс по шагам на тестовых данных, показывает, какое условие уводит запуск в какую ветку, и не отправляет ни писем, ни сообщений в мессенджерах, ни SMS. Тестовое тело не выдумывайте — возьмите пример из документации провайдера, а лучше сохранённый настоящий запрос. Мелкие расхождения между ними обычно и составляют всю проблему.

После публикации дверь назад тоже должна оставаться открытой. Каждое сохранение хранится как версия, поэтому сломанный процесс возвращается к прежней версии одним нажатием, а текущее состояние сохраняется перед откатом — вы не потеряете единственную работающую копию, пока пытаетесь её починить. Именно эта страховка определяет, решится ли кто-нибудь трогать живой процесс.

Почувствует ли клиент внезапный наплыв вебхуков?

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

Ограничения скорости и рабочего окна сглаживают этот всплеск: вы задаёте потолок запусков в час, день или неделю, лимит на одного человека, паузу между шагами и окно рабочего времени, за пределами которого отправка ждёт утра. Ошибка списания, пришедшая в 03:40, попадает в CRM сразу, а сообщение клиенту уходит в девять. Та же логика окна работает, когда вы решаете, в какое время уходят напоминания о записи.

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

Где автоматизация должна остановиться и позвать человека?

По мере взросления связки процессы удлиняются, и однажды внешний запрос начинает запускать шаг с серьёзными последствиями: блокировка аккаунта, отметка о расторжении договора, инициированный возврат. Такие шаги не обязаны быть автоматическими. Им достаточно быть быстрыми.

Шаг ожидания согласования останавливает процесс перед рискованным действием, отправляет уведомление выбранному человеку и не пропускает запуск дальше без одобрения, даже когда срок вышел. Информация попадает в CRM за секунды, а решение остаётся за человеком. Критерии этой границы обсуждаются в материале о том, где остановить автоматизацию и оставить человека; на стороне вебхуков рабочее правило простое: перед каждым необратимым шагом должен стоять человек.

Чтобы связка оставалась честной, регулярно открывайте автоматическую диагностику. Оборванный шаг, ни разу не сработавший процесс или неподключённый канал — это тихие неисправности: никто не жалуется, потому что никто не замечает отсутствия того, что должно было случиться. Вебхук-процесс с нулём запусков почти всегда означает, что адрес вписали не в то поле на стороне отправителя.

Если хотите попробовать запустить процесс событием из вашей внешней системы, создайте аккаунт в Rocketly и опишите первую точку приёма за несколько минут.

Частые вопросы

Кто создаёт точку приёма вебхука, нужен ли разработчик?

Адрес формируется на стороне CRM во время сборки процесса: среди вариантов множественных триггеров вы выбираете вебхук и получаете готовый адрес. Техническая помощь обычно нужна на другой стороне — какой тип события привязать к этому адресу и куда вписать секрет подписи, зависит от панели провайдера.

Что делать, если внешняя система не поддерживает подпись?

Есть два частичных заменителя. Добавьте в адрес трудноугадываемый фрагмент и требуйте, чтобы данные из тела совпадали с уже существующей записью в CRM. Подпись это не заменяет полностью, поэтому к неподписанным источникам разумнее не подключать необратимые шаги.

Может ли один вебхук запускать несколько процессов?

Может, но рекомендуемая схема — один входной процесс, вызывающий подпроцессы. Три независимых процесса на одном адресе делают порядок выполнения непредсказуемым, а единая точка входа один раз оценивает условие и передаёт работу нужному подпроцессу.

Что если событие относится к человеку, которого нет в CRM?

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