Сценарий в Make или Zapier собирается за вечер. Через месяц он молча перестаёт отправлять заявки в таблицу, и никто не замечает неделю. No-code связки не хуже и не лучше обычного кода: у них свои сильные стороны и свои места, где они трескаются.

Где no-code связки работают лучше всего?

Там, где процесс короткий, повторяется и состоит из понятных шагов. Заявка с формы попала в таблицу и ушла уведомлением в Telegram. Оплата прошла, письмо клиенту отправлено, статус в CRM (системе учёта клиентов) изменился. Три-пять шагов, один источник, один результат.

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

Но у любой схемы есть предел. Какой?

Что ломает связки чаще всего?

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

Ни одна не видна при создании сценария. Они проявляются на реальных данных, поэтому проверять связку нужно не на трёх тестовых заявках, а на двух-трёх неделях живой работы.

Что делает сама платформа?

Как платформа реагирует на сбой?

Зависит от настроек, и значения по умолчанию не всегда те, что вы ожидаете. В Make, например, сохранение незавершённых выполнений (Store incomplete executions) по умолчанию выключено. Если сценарий упал на ошибке, а сохранение не включено, неудавшийся запуск остаётся только в журнале, а повторить его с теми же данными нельзя. Обработчик повтора (Retry) по умолчанию пробует три раза с интервалом 15 минут, и часть ошибок, например превышение лимита запросов, платформа повторяет сама. Но ошибка в самих данных от повторов не исчезнет: пятая попытка с пустым полем кончится так же, как первая.

Значит, нужен человек, который узнает о сбое первым.

Какие три защиты ставить в каждую связку?

Уведомление об ошибке: в Telegram или на почту, а не только запись в журнале платформы. Проверка входных данных до записи: пустое поле или неверный формат отправляется в отдельный список на разбор. Защита от дубля: идентификатор заявки, по которому сценарий понимает, что эту заявку уже обработал.

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

Что сделать сегодня?

1. Откройте историю запусков и найдите ошибки за последние две недели.
2. Проверьте, включено ли сохранение неудавшихся запусков.
3. Добавьте в самую важную связку уведомление об ошибке.