Сергей Степанов – Zero-code. Продажа ботов и автоматизаций под ключ (страница 4)

Добавьте сведения о сроке подписки и контакте администратора. Просроченная оплата платформы и программный дефект могут выглядеть одинаково для клиента: заявки перестали проходить. Без реестра вы потратите время на отладку исправного сценария.

Проверка готовности

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

Если функция требует тарифа, которого пока нет, зафиксируйте это как зависимость. Не строите коммерческое обещание на временном пробном доступе без обсуждения оплаты после его окончания. Готовое окружение должно воспроизводиться, иначе даже простая автоматизация останется одноразовой демонстрацией.

Глава 7. Проект в

Make

от формы до сделки в Битрикс24

Результат и условия учебной сборки

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

Используйте отдельную тестовую воронку Битрикс24. Для первого запуска достаточно сделки с описанием и внешним номером; контакт будет подключён после освоения API в следующем техническом разделе. Такое разделение позволяет сначала проверить передачу заявки, затем добавить поиск человека и связь сущностей.

Понадобятся аккаунт Make с доступом к Webhooks, Data store и HTTP, тестовый портал CRM и REST-доступ с правом создания сделки. Доступность API, региональные ограничения и способы оплаты проверьте до сборки. Не подключайте учебную цепочку к рабочей форме компании.

Шаг 1. Подготовьте входные данные

Создайте новый сценарий и добавьте Webhooks — Custom webhook. Назовите вебхук «ТехСервис учебный вход». Полученный адрес храните в закрытых настройках источника. Он понадобится при отправке тестового POST-запроса, но не должен попадать в портфолио.

В HTTP-клиенте, например Postman, выберите POST, вставьте адрес вебхука и задайте заголовок Content-Type со значением application/json. В Body выберите raw и JSON. Отправьте следующий объект, предварительно включив ожидание данных через Run once:

{

"request_id": "FORM-001",

"source": "test_form",

"client_name": "Тестовый клиент",

"contact_phone": "TEST-PHONE-001",

"service_type": "washer",

"problem_text": "Не сливает воду",

"confirmed": true

}

TEST-PHONE-001 — специально не телефон. В этом проекте он передаётся как текст в описании, без звонков и создания телефонного поля. Когда подключите настоящий контакт, замените учебный маркер допустимым тестовым значением, согласованным владельцем CRM. Нельзя брать случайный реальный номер.

Откройте выход вебхука. Убедитесь, что request_id и problem_text определены как строки, confirmed — как логическое значение. Если вместо отдельных полей пришла одна строка, проверьте Content-Type и валидность JSON. Повторно определите структуру по корректному образцу, прежде чем подключать остальные модули.

Шаг 2. Сохраните заявку до обращения к

CRM

Создайте Data store с названием ts_requests. Ключ записи будет равен request_id. Добавьте текстовые поля state, source, client_name, contact_phone, service_type, problem_text, crm_id и last_error. Для учебного журнала crm_id удобно хранить как строку: пустое значение означает, что ID пока не получен.

После вебхука поставьте Router с двумя ветками. На допустимой ветке установите фильтр: request_id не пустой, problem_text не пустой, confirmed равен true. На второй ветке задайте обратное условие и Webhook response с кодом 400 и телом {"status":"invalid_input"}. Обе ветки не должны срабатывать одновременно; фильтр первой ветки не ставится перед Router, иначе недопустимые данные исчезнут до ответа.

В допустимой ветке добавьте Data store — Check the existence of a record. Выберите ts_requests и сопоставьте Key с request_id входного вебхука. Поставьте Router: новая запись идёт на создание, существующая — на чтение через Get a record. В новой ветке используйте Add/replace a record: Key равен request_id, state равен received, остальные поля берутся из входа, crm_id и last_error пустые.

До теста включите последовательную обработку вебхуков в настройках сценария. В разных версиях настройка может называться Sequential processing или Process data in order. Она нужна, чтобы две доставки не выполнили проверку отсутствия одновременно. Ограничение действует внутри этого сценария: второй сценарий, ручной запуск или иной записывающий процесс могут обойти его. Во время учебного опыта оставьте единственного исполнителя для ts_requests.

Шаг 3. Проверьте доступ к Битрикс24

Создайте входящий вебхук CRM с минимально необходимыми правами. Его базовый адрес содержит домен портала, пользователя и секрет. В HTTP — Make a request укажите POST к методу crm.item.fields, Content-Type application/json и тело {"entityTypeId":2}. Это запрос схемы полей сделки, без создания объекта.

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

В учебной записи адрес HTTP-модуля складывается из закрытого базового адреса REST-вебхука и имени crm.item.add. Не вставляйте секрет в названия модулей. У HTTP-модуля включите разбор JSON-ответа, если такая настройка доступна в его версии. Сначала добейтесь чтения схемы: создание сделки с неработающими правами только усложнит диагностику.

Шаг 4. Сформируйте тело запроса без ручной склейки

Добавьте JSON — Create JSON и создайте структуру по следующему образцу:

{

"entityTypeId": 2,

"fields": {

"title": "Учебная заявка FORM-001",

"comments": "Не сливает воду. Контакт TEST-PHONE-001",

"originatorId": "ts_form",

"originId": "FORM-001"

}

}

Затем замените образцы динамическими значениями: title собирается из текста «Учебная заявка» и request_id; comments содержит problem_text и контактный маркер; originId равен request_id. originatorId оставьте постоянным ts_form. JSON-модуль должен экранировать кавычки и переносы строк. Не собирайте тело обычной строкой с подставленным клиентским текстом.

В HTTP-модуле crm.item.add передайте выход Create JSON как тело application/json. Если используемая версия HTTP предлагает собственный конструктор JSON, можно сопоставить поля в нём вместо отдельного модуля. В обоих случаях массивы, числа и логические значения должны сохранить типы.

Пример сокращённого успешного ответа: {"result":{"item":{"id":104,"title":"Учебная заявка FORM-001"}}}. Число 104 вымышлено. Извлеките result.item.id из фактического ответа, затем обновите запись ts_requests: state равен crm_created, crm_id равен полученному ID. Перед обновлением поставьте Router: успешная ветка требует отсутствия поля error и непустого result.item.id. Другой ответ направьте в review_required, сохранив причину; в этой ветке подтверждение created не отправляется. При обновлении сохраните исходные поля заявки; не заменяйте их пустыми значениями.

Шаг 5. Верните подтверждённый результат

Последним модулем новой ветки добавьте Webhook response: код 200, Content-Type application/json. Тело сформируйте через JSON-модуль: status равен created, request_id берётся из входа, crm_id — из ответа CRM. Пример результата: {"status":"created","request_id":"FORM-001","crm_id":"104"}.

Откройте сделку вручную. Проверьте описание, внешний номер и воронку. Только после этого отправьте FORM-002 с другим текстом. В CRM должны появиться две разные заявки с соответствующими описаниями. Если текст совпал, значит где-то остался образец вместо сопоставления.

В ветке существующей записи Get a record должен получить сохранённый state и crm_id. Если ID есть, верните 200 со status already_created и прежним crm_id. При этом ветка не вызывает crm.item.add. Повторите FORM-001: число сделок не должно увеличиться.

Если запись существует, но crm_id пустой, верните 202 со status review_required и сохранённым request_id. Такой ответ означает необходимость проверки, а не создание сделки. В этой учебной версии незавершённые заявки восстанавливаются вручную по следующей процедуре. Нельзя отправлять их снова на создание только потому, что ID отсутствует в журнале.

Шаг 6. Обработайте неопределённый результат

На HTTP-модуль создания поставьте обработчик ошибки. При timeout либо неопределённом сетевом отказе обновите state до review_required и запишите короткую причину в last_error. Сначала убедитесь на отключённом тестовом подключении, что обработчик действительно выполняется и исходная запись сохраняется. После записи ошибки верните Webhook response с кодом 202 и телом {"status":"review_required","request_id":"[исходный номер]"}, сформированным через JSON. Завершите обработчик Retry с Automatically complete execution равным No; в прежних интерфейсах аналогичная директива называлась Break. В настройках включите Store incomplete executions. Сохранённое выполнение не запускайте повторно до сверки CRM: ручная кнопка повтора также может создать дубль. Не используйте Resume с вымышленным ответом CRM.