В конструкторе сценариев надёжно собирается всё, что сводится к перекладыванию данных между системами по понятному правилу: приём заявок, синхронизация остатков, уведомления, напоминания, ежедневные сверки и отчёты. Двенадцать таких сценариев для компании на 60 человек собираются за 131 час работы инженера и дают около 89 100 операций в месяц. Плохо собирается всё остальное: длинные транзакции, массовые выгрузки, тяжёлые файлы и логика, в которой важны порядок действий и возможность откатиться назад.
Второе, что нужно знать до старта, — состав рынка. Zapier и Make (ранее Integromat) в России недоступны: оплата и поддержка для российских компаний не работают, и строить на них новые процессы нельзя. Живой контур на сентябрь 2026 года — n8n на своём сервере, Albato, ApiX-Drive и Nodul. У n8n оплата облачного тарифа из России проблемна, поэтому в стране прижился self-hosted: платформа ставится на собственный сервер. Побочный эффект оказался главным аргументом — данные не покидают ваш контур, и требование 152-ФЗ о хранении персональных данных в России закрывается самой архитектурой.
Ниже — разбор без вендорского оптимизма: как устроен сценарий внутри, двенадцать конкретных задач с часами и операциями по каждой, что конструктор делает надёжно и что делает с оговорками, во что обходится своя установка за год, где проходят два денежных порога и когда low-code не подходит категорически. Все цены и статусы платформ — по состоянию на сентябрь 2026 года; тарифы меняются, поэтому арифметику мы показываем целиком, чтобы вы могли пересчитать её на своих числах.
Как устроен сценарий: триггер, узлы, ветвление, состояние
Сценарий — это цепочка из четырёх сущностей, и понимания этих четырёх слов достаточно, чтобы читать чужую автоматизацию и оценивать её стоимость. Триггер запускает прогон: пришло письмо, сработал вебхук, наступило время по расписанию. Узел выполняет одно действие над данными: получить, преобразовать, отправить, сравнить. Ветвление направляет запись по одной из веток по условию. Состояние — это то, что сценарий помнит между прогонами: какая запись уже обработана, на чём остановились в прошлый раз.
Разберём на самом частом сценарии — приёме заявок из почты. Триггер: новое письмо на общем ящике. Дальше двенадцать узлов: скачать вложения, отсечь автоответы и рассылки, вытащить из тела письма имя, телефон и суть обращения, нормализовать телефон к единому формату, найти клиента в CRM по этому телефону, при отсутствии — создать контакт, создать сделку, приложить вложения, поставить задачу ответственному, отправить уведомление в мессенджер, записать факт обработки в журнал, ответить отправителю подтверждением. Ветвлений три: письмо от известного клиента или от нового, есть телефон или нет, обращение по существующей сделке или новое. Состояние одно, но критичное: идентификатор письма, чтобы повторный прогон не создал вторую сделку.
Единица тарификации в интеграционных платформах: одно выполнение одного узла над одной записью. Сценарий из двенадцати узлов, обработавший 900 писем за месяц, потратит 10 800 операций, а не 900. Отсюда правило, которое экономит больше всего денег: считать надо не количество запусков, а произведение запусков на число узлов, и лишний узел проверки в начале цепочки стоит дороже, чем кажется.
Горизонтальная схема сценария. Слева блок «Триггер: новое письмо». Дальше цепочка из двенадцати прямоугольных узлов с подписями: скачать вложения, отсечь автоответы, извлечь поля, нормализовать телефон, найти клиента в CRM, создать контакт, создать сделку, приложить вложения, поставить задачу, уведомить в мессенджер, записать в журнал, ответить отправителю. Три ромба-ветвления подписаны: «известный клиент?», «телефон есть?», «новое обращение?». Снизу отдельный блок «Состояние: идентификатор письма» со стрелкой-петлёй к началу и подписью «защита от дублей». Справа сноска: «900 писем × 12 узлов = 10 800 операций в месяц».
Разница между рабочим сценарием и демонстрацией с конференции — целиком в двух последних пунктах. Демонстрация показывает счастливый путь: письмо пришло, поля извлеклись, сделка создалась. Рабочий сценарий половину своих узлов тратит на несчастные пути: пустое поле, отвалившийся токен, дубль, письмо от робота, вложение размером в 40 МБ. Поэтому оценка «тут работы на два часа» почти всегда означает, что человек посчитал счастливый путь.
Двенадцать сценариев с часами и операциями
Модельная компания: 60 человек, оптовая торговля с собственным сайтом, 1С:УТ в качестве учётной системы, CRM, общий почтовый ящик, поток около 900 заявок и 1 200 заказов в месяц. Все двенадцать сценариев ниже — из реальной практики, а не из витрины шаблонов. Часы указаны на сборку и отладку до состояния «работает на боевых данных две недели без ручных вмешательств», включая обработку ошибок.
| Сценарий | Часы на сборку | Операций в месяц | Что ломает его чаще всего |
|---|---|---|---|
| Приём заявок с сайта и из почты: письмо или форма превращается в сделку с заполненной карточкой | 14 | 10 800 | Нестандартное письмо: пересылка, подпись вместо темы, суть обращения во вложении |
| Уведомление ответственному в мессенджер с карточкой заявки и кнопкой «взял в работу» | 3 | 3 600 | Смена канала связи: адрес бота поменялся — сценарий молчит, но не падает |
| Синхронизация остатков 1С:УТ и сайта каждые 15 минут | 16 | 14 400 | Опрос вместо обмена по событию: больше половины прогонов вхолостую |
| Выгрузка новых заказов сайта в 1С с созданием контрагента и подбором номенклатуры | 10 | 9 600 | Дубли контрагентов при разном написании названия и отсутствии ИНН |
| Ежедневная сверка банковской выписки с реестром выставленных счетов | 12 | 1 400 | Частичная оплата и один платёж сразу по трём счетам |
| Напоминание о просроченной дебиторке: письмо клиенту и задача менеджеру | 6 | 1 320 | Часовые пояса и выходные: письма уходят клиенту в субботу в 03:40 |
| Мониторинг отзывов и упоминаний, немедленный алерт при негативе | 8 | 7 500 | Изменившийся формат ответа внешнего источника — сценарий тихо отдаёт пустоту |
| Обработка входящих накладных: письмо с PDF, распознавание, строка в учёте | 20 | 6 600 | Скан плохого качества и нетиповая печатная форма поставщика |
| Онбординг сотрудника: заявка кадровика, заведение доступов, задачи ответственным | 10 | 100 | Права в системах меняют руками, и сценарий об этом не узнаёт |
| Ежедневная сводка руководителю: выручка, заявки, просрочки — в мессенджер к 09:00 | 8 | 300 | Долгая выборка: сценарий упирается в таймаут запроса к базе |
| Контроль SLA обращений: проверка очереди каждые 10 минут и эскалация руководителю | 6 | 17 280 | Самый дорогой сценарий парка: 96 % прогонов не находят ничего |
| Сбор сообщений из мессенджеров в одну ленту обращений: адаптер канала | 18 | 16 200 | Вложения: голосовые сообщения и файлы больше лимита узла |
| Итого | 131 час | 89 100 | — |
Из таблицы видно главное, что скрывают обзоры конструкторов: стоимость сценария почти не связана с его пользой. Уведомление в мессенджер собирается за три часа и снимает ежедневное «а кто взял эту заявку». Обработка накладных требует двадцати часов и стоит в семь раз дороже, хотя обе строки в презентации выглядят одинаково как «автоматизация». Планировать надо по часам сборки и по операциям, а не по количеству пунктов в списке. Отдельно отметим первый сценарий: заполнение карточки клиента данными из письма — самостоятельная задача, у которой в каталоге есть готовое решение с разбором полей и защитой от дублей, и на потоке от 500 заявок в месяц брать его готовым дешевле, чем собирать четырнадцать часов.
Контроль SLA опрашивает очередь каждые 10 минут: 4 320 прогонов в месяц по четыре узла — 17 280 операций, при том что эскалаций за месяц набирается около 170. То есть 96 % прогонов не находят ничего и оплачиваются полностью. Тот же контроль, перестроенный на событие «обращение изменило статус», расходует примерно 900 операций. Разница в 16 380 операций при цене 0,15 ₽ — это 2 457 ₽ в месяц и около 29 500 ₽ в год на одном-единственном сценарии.
Горизонтальная диаграмма из двенадцати строк-сценариев. У каждой строки две полосы разного тона: «часы на сборку» (шкала 0–20) и «операций в месяц» (шкала 0–18 000). Строка «Контроль SLA» выделена рамкой: 6 часов сборки, но 17 280 операций, подпись «96 % прогонов вхолостую». Строка «Обработка накладных» подписана «20 часов — самая дорогая сборка». Внизу итоговая полоса: «131 час, 89 100 операций в месяц». Все подписи по-русски.
Сколько стоит держать эти двенадцать сценариев год
Считаем свою установку n8n на российском хостинге: сервер, отдельная база, резервное копирование, мониторинг, администрирование и часы внутреннего сотрудника, который правит сценарии. Ставка инженера подрядчика — 3 500 ₽/час, внутренний час сотрудника — 1 100 ₽ (оклад 120 000 ₽ плюс взносы, поделённые на 160 рабочих часов). Установка платформы считается отдельно от эксплуатации.
Теперь сравнение с облачной платформой на том же объёме. При модельной цене 0,15 ₽ за операцию (по массовым тарифам российских площадок вилка укладывается в 0,10–0,25 ₽ и зависит от объёма) 89 100 операций в месяц дают 160 380 ₽ в год подписки. Часы внутреннего владельца остаются те же — 79 200 ₽. Итого 239 580 ₽ против 295 400 ₽ у своей установки: облако дешевле примерно на 56 000 ₽ в год. Это и есть цена того, чтобы данные не покидали ваш контур, — и её честнее назвать вслух, чем прятать за словами о «полном контроле».
Дальше начинается арифметика, которую вендоры не показывают, потому что она работает против подписки. Годовые расходы своей установки почти не зависят от объёма: сервер и администратор стоят одинаково при 50 000 и при 200 000 операций. Расходы облака растут линейно. Приравняв 216 200 ₽ фиксированных затрат к формуле «0,15 ₽ × N × 12», получаем точку равенства около 120 000 операций в месяц по всему парку сценариев. С учётом разовой установки, размазанной на три года, порог сдвигается примерно к 133 000. Ниже этих чисел облако дешевле, выше — своя установка, и никакого другого содержания у спора «облако против своего сервера» с точки зрения денег нет. Всё остальное содержание — юридическое.
Своя установка на сервере в России действительно снимает вопрос трансграничной передачи и хранения персональных данных за рубежом. Она не снимает остального: согласий субъектов, поручения обработки для подрядчика, который администрирует контур, журналирования доступа, ротации ключей API и защиты резервных копий. Мы регулярно видим установки n8n, где бэкапы базы прогонов с телефонами клиентов лежат в общедоступной папке на том же сервере. Формально данные в России. Фактически это утечка, которая ждёт своего часа.
Что конструктор делает надёжно
Надёжно — значит работает месяцами без вмешательства и не требует объяснять, почему сегодня результат другой. Таких классов задач пять, и они покрывают большую часть повседневной рутины компании.
- Перекладывание данных между системами по фиксированному правилу. Заявка из формы в CRM, заказ с сайта в учётную систему, контакт из одной базы в другую. Данных мало, правило одно, результат проверяется сравнением двух записей.
- Уведомления и эскалации. Сообщение ответственному, алерт при негативном отзыве, напоминание о просрочке. Цена ошибки низкая: непришедшее уведомление заметит человек, а лишнее просто раздражает.
- Действия по расписанию. Ежедневная сводка, еженедельная выгрузка, ежемесячная сверка. Расписание — самый предсказуемый триггер: он не зависит от чужого сервиса и всегда воспроизводим.
- Простые сверки двух источников. Выписка против реестра счетов, остатки на сайте против остатков в учёте, список задач против списка сделок. Логика сводится к соединению по ключу и списку расхождений.
- Маршрутизация и назначение. Распределить обращение по правилу, назначить ответственного по очереди или по региону, поставить метку. Всё, что описывается таблицей соответствий, конструктор делает лучше человека и без выгорания.
Две задачи из этого списка мы вынесли в отдельные решения каталога с фиксированным составом работ — ежедневную сверку документов и классификацию входящих обращений. Логика там ровно та, что описана выше, но в поставку уже входят обработка ошибок, идемпотентный ключ, журнал обработанного и порядок приёмки, поэтому собирать их с нуля обычно дороже, чем взять готовое.
Общее у этих пяти классов одно: результат каждого прогона проверяется независимо. Можно взять запись, повторить путь руками и увидеть тот же результат. Как только это свойство теряется, конструктор перестаёт быть надёжным инструментом — не потому, что он плох, а потому, что вы больше не можете доказать, что он работает правильно.
Что он делает с оговорками
Здесь конструктор не отказывается работать — он работает и незаметно накапливает проблемы. Это опаснее прямого отказа: сценарий зелёный, отчёты приходят, а данные расходятся.
- 1Длинные транзакции
Операция, в которой пять шагов должны выполниться все или ни один: списать остаток, создать отгрузку, провести оплату, отправить документ, уведомить клиента. Конструктор выполнит первые три и упадёт на четвёртом — и оставит систему в состоянии, которого в вашей учётной политике не предусмотрено. Обходится это компенсирующими шагами, но их надо спроектировать, и это уже разработка внутри конструктора.
- 2Массовые выгрузки
Прогон, который тянет 20 000 строк из базы, держит их в памяти и отдаёт по частям. Конструктор рассчитан на поток записей, а не на пакетную обработку: память прогона конечна, таймауты чужих API короче, чем ваша выгрузка. Практический порог — около 500 записей за прогон; дальше нужна разбивка на страницы и хранение позиции, то есть снова разработка.
- 3Сложная бизнес-логика
Расчёт скидки с двенадцатью условиями, подбор тарифа, распределение оплаты по счетам, любая математика с округлениями. В визуальном виде это превращается в дерево из тридцати ветвлений, которое невозможно ни прочитать, ни протестировать. Такую логику выносят в отдельный сервис или в учётную систему, а конструктор оставляют на роль курьера.
- 4Крупные файлы и медиа
Сканы, видео с камер, архивы фотографий. У узлов есть лимит на размер тела запроса, и упираются в него всегда неожиданно — на пятидесятом мегабайте от нового поставщика. Правильная схема: файл кладётся в хранилище, по сценарию ходит ссылка, а не содержимое.
- 5Повторный прогон без последствий
Любой сценарий рано или поздно перезапускают: отвалился внешний сервис, ошиблись в настройке, вручную дёрнули после сбоя. Если у сценария нет идемпотентного ключа, повтор создаёт вторые сделки, вторые письма и вторые платёжные задачи. Конструктор ничем не мешает сделать ключ, но и ничем не заставляет.
Признак записи, по которому сценарий узнаёт: эту запись он уже обрабатывал. Идентификатор письма, номер заказа, хеш содержимого. Перед созданием сделки сценарий проверяет ключ и при совпадении завершается без действий. Без ключа любой повторный прогон — а он случится — превращается в дубли, и находят их обычно через месяц по жалобам клиентов на двойные звонки.
Сравнение в две колонки. Левая «Надёжно»: перекладывание данных по правилу, уведомления и эскалации, действия по расписанию, простые сверки двух источников, маршрутизация по таблице. Правая «С оговорками»: длинные транзакции, массовые выгрузки (порог 500 записей за прогон), сложная бизнес-логика, крупные файлы (передавать ссылку, не содержимое), повторный прогон без идемпотентного ключа. Под колонками общая подпись-разделитель: «Проверка одна: можно ли повторить прогон руками и получить тот же результат».
Российский контур на сентябрь 2026: чем платят и чем не платят
Почти все сравнения интеграционных платформ в выдаче написаны их же партнёрами и заканчиваются рекомендацией платформы заказчика обзора. Мы платформы не перепродаём, поэтому сравниваем по инженерным критериям и называем ограничения каждой. Тарифы и списки коннекторов меняются — проверяйте их на дату принятия решения, а таблицей пользуйтесь как набором вопросов, которые надо задать.
| Критерий | n8n на своём сервере | Albato | ApiX-Drive | Nodul |
|---|---|---|---|---|
| Где исполняется сценарий и лежат логи прогонов | На вашем сервере, данные не покидают контур | На стороне платформы, юрлицо и серверы в РФ | На стороне платформы, российская площадка в реестре Минцифры | На стороне платформы, российская разработка |
| За что платите | За сервер и администратора, объём операций на счёт не влияет | За операции и тарифный план | За связи и объём, от ~2 200 ₽/мес на младшем тарифе | За тарифный план платформы |
| Как счёт ведёт себя при росте потока | Не меняется до упора в железо | Растёт линейно вместе с операциями | Растёт ступенями при переходе на старший тариф | Растёт по тарифной сетке |
| Произвольный код внутри сценария | Есть узел кода — сложную логику можно оставить внутри | Ограничено набором действий коннекторов и выражениями | Ограничено набором действий коннекторов | Ограничено набором узлов, сильная сторона — ИИ-узлы |
| Коннекторы к российскому стеку: 1С, Битрикс24, amoCRM, RetailCRM, МойСклад, MAX | Универсальный HTTP-узел, конкретные связки пишутся руками | Готовые коннекторы — основное преимущество платформы | Готовые коннекторы, упор на простые связки «система А → система Б» | Готовые коннекторы, набор моложе зарубежных аналогов |
| Экспорт и версионирование сценария | Выгружается в файл, кладётся в репозиторий, откат по версиям | Проверяйте наличие и полноту экспорта до старта | Проверяйте наличие и полноту экспорта до старта | Проверяйте наличие и полноту экспорта до старта |
| Кто чинит инфраструктурный сбой | Вы или ваш подрядчик, круглосуточно ваша зона ответственности | Платформа отвечает за площадку, вы — за логику | Платформа отвечает за площадку, вы — за логику | Платформа отвечает за площадку, вы — за логику |
| Оплата из России | Не нужна: платите хостеру рублями | Рублями по договору с российским юрлицом | Рублями по договору | Рублями по договору |
Теперь ограничения, которые в вендорских обзорах не встречаются. У n8n на своём сервере их три: нужен администратор и дежурство, иначе вы узнаете о падении от менеджеров; вы сами отвечаете за обновления и их совместимость со сценариями; готовых коннекторов к российским системам почти нет, всё собирается через HTTP-узел, а это часы работы на каждую связку. У облачных платформ ограничение общее и главное: через них проходят ваши персональные данные, а значит нужен договор, поручение обработки и понимание, что именно и на какой срок остаётся в логах прогонов. Второе общее ограничение — переносимого формата сценария между платформами не существует, и переезд с любой из них на любую другую означает пересборку руками. Третье — глубина логики: там, где n8n позволяет написать двадцать строк кода, облачный конструктор потребует собрать десять узлов или отказаться от задачи.
Частные ограничения тоже стоит проговорить. Albato сильна коннекторами и российской пропиской, но тарификация по операциям означает, что успешный рост потока автоматически увеличивает счёт — экономику надо пересчитывать при каждом удвоении объёма. ApiX-Drive удобна для простых связок «одна система — другая система» и присутствует в реестре Минцифры, что важно для госзаказчика, но сложные ветвления и хранение состояния делать на ней неудобно. Nodul моложе зарубежных аналогов: сильные ИИ-узлы, но набор готовых коннекторов и объём публичных материалов меньше, поэтому наличие нужного коннектора надо проверять до подписания договора, а не после. И для всех трёх работает правило: спросите про экспорт сценария в файл ещё на демонстрации. Ответ на этот вопрос говорит о вашей будущей свободе больше, чем любой список интеграций.
Карта в две зоны. Слева серая зона «Недоступны в РФ» с двумя перечёркнутыми узлами: Zapier, Make (ранее Integromat), подпись «оплата и поддержка не работают». Справа рабочая зона «Живой контур, сентябрь 2026» с четырьмя узлами: n8n на своём сервере (пометка «данные в вашем контуре, 216 200 ₽/год»), Albato, ApiX-Drive (пометка «реестр Минцифры»), Nodul. От каждого узла стрелки к общему блоку «1С, Битрикс24, amoCRM, RetailCRM, МойСклад, MAX». Под картой линия порога с подписью «120 000 операций в месяц — точка, где своя установка становится дешевле облака».
Три признака, что сценарий пора переписывать в код
Переписывать в код нужно не «сложные» сценарии — это слово ничего не значит. Нужно переписывать те, у которых сломалось одно из трёх инженерных свойств: читаемость, вместимость прогона и воспроизводимость. Плюс четвёртый признак, чисто денежный.
- 1Сценарий перевалил за 25 узлов и три вложенных ветвления. Проверка простая: новый человек должен понять, что делает сценарий, за минуту просмотра. Если для этого нужен рассказ автора, схема уже не документация, а декорация, и любая правка в ней делается наугад.
- 2За один прогон обрабатывается больше 500 записей или файл тяжелее 15 МБ. Конструктор держит данные прогона в памяти; дальше начинаются таймауты, частичные обработки и потерянные хвосты, которые обнаруживаются по расхождению в отчётах через недели.
- 3Прогон нельзя повторить безопасно. Нет идемпотентного ключа, нет журнала обработанных записей, повторный запуск создаёт дубли. Это не косметика: именно из-за этого свойства сценарий превращается в объект, который страшно трогать, и его перестают чинить вовремя.
- 4Денежный признак: один сценарий стабильно даёт больше 121 000 операций в месяц. На этом объёме собственный сервис с той же логикой окупается за три года — расчёт ниже.
Арифметика воспроизводится в одну строку: расходы конструктора за три года равны 108 400 ₽ постоянных плюс 5,4 ₽ на каждую операцию месячного потока, расходы своего сервиса — 762 000 ₽ почти независимо от объёма. Приравняйте и получите свой порог. Подставьте вместо 0,15 ₽ цену операции из своего счёта, вместо 420 000 ₽ — оценку разработчика, и решение перестанет быть предметом веры. При 25 000 операций в месяц конструктор дешевле втрое, и никакая любовь к чистому коду этого не перевешивает.
График. Ось X — операций в месяц по одному сценарию, от 0 до 250 000. Ось Y — расходы за 36 месяцев, рубли. Наклонная линия «конструктор» стартует с 108 400 ₽ и растёт на 5,4 ₽ за операцию. Горизонтальная линия «свой сервис» на 762 000 ₽. Точка пересечения подписана «121 000 операций в месяц». Отдельной точкой на наклонной линии отмечено «25 000 операций — 243 400 ₽». Подписи осей и обеих линий по-русски.
Тридцатый сценарий: как парк превращается в клубок
Двенадцать сценариев из таблицы выше — управляемый парк. Проблемы начинаются между двадцатым и тридцатым, причём не от числа, а от того, что к этому моменту сценарии обычно уже запускают друг друга. Один пишет запись, второй реагирует на неё, третий по расписанию проверяет результат второго. Граф запусков нигде не нарисован, живёт в голове одного человека, и этот человек уходит в отпуск.
Признаки ранней стадии видно задолго до катастрофы: два сценария делают почти одно и то же, но чуть по-разному; есть сценарии, назначение которых никто не помнит; кто-то раз в неделю перезапускает прогон руками и считает это нормой; клиенты получают письма от отправителя, которого нет ни в одной рассылке; отключение любого сценария никто не берётся оценить. Лечится это дёшево и скучно: правило именования, владелец у каждого сценария, карта запусков на одном листе и карантин на 30 дней для всего, чьё назначение не смог объяснить ни один сотрудник. Собранная за два часа карта окупается на первом же инциденте, потому что отвечает на вопрос «что сломается, если это выключить», за минуту вместо трёх дней.
Две панели. Левая «Как есть»: тридцать безымянных узлов, соединённых хаотично пересекающимися стрелками, три узла помечены знаком вопроса «владельца нет», один — «перезапускают руками». Правая «Как надо»: те же тридцать узлов, разложенные по четырём дорожкам с подписями «Продажи», «Учёт», «Склад», «Служебные», стрелки идут сверху вниз, у каждого узла подпись владельца, три узла в рамке «карантин 30 дней». Внизу подпись: «карта собирается за два часа».
Чек-лист перед сборкой сценария
Семь вопросов, на которые надо ответить письменно до того, как открыт конструктор. Половина сценариев на этом этапе отменяется — и это лучший исход, потому что несобранный сценарий не надо потом поддерживать.
- 1Какое событие запускает сценарий и есть ли у источника вебхук. Если вебхука нет и придётся опрашивать по расписанию, сразу посчитайте операции: опрос каждые 10 минут — это 4 320 прогонов в месяц независимо от полезной работы.
- 2Сколько записей проходит за прогон и в пике. Больше 500 — планируйте разбивку на страницы, больше 2 000 — планируйте отдельный сервис.
- 3Какие поля обязательны и что делать, если поле пустое. Пустое поле — самая частая причина тихого сбоя: сценарий отработает и создаст запись-пустышку, которую заметят на отчётности.
- 4Есть ли идемпотентный ключ. Назовите конкретное поле, по которому вы отличите повтор. Если такого поля нет, его надо придумать до сборки, а не после первого дубля.
- 5Что происходит при сбое каждого внешнего вызова: повторить, пропустить, остановить сценарий. У этих трёх реакций разные последствия, и выбирать надо для каждого узла отдельно.
- 6Кому и куда приходит уведомление о сбое и кто обязан на него отреагировать в тот же день. Алерт в чат, который никто не читает, равносилен его отсутствию.
- 7Кто владелец сценария и где лежит его описание на полстраницы: что делает, какие системы трогает, что сломается при отключении. Без этих трёх строк сценарий через год становится неприкасаемым.
Вертикальная схема-воронка из семи блоков-вопросов сверху вниз: событие и вебхук, объём за прогон, обязательные поля, идемпотентный ключ, реакция на сбой, адресат алерта, владелец и описание. У блока «объём за прогон» боковая пометка «>500 записей — постраничная обработка, >2 000 — отдельный сервис». У блока «событие» пометка «опрос каждые 10 минут = 4 320 прогонов в месяц». Справа от воронки узкий отвод с подписью «сценарий отменён — и это хороший исход».
Когда low-code не подходит категорически
Мы зарабатываем в том числе на сборке сценариев, поэтому этот раздел стоит читать внимательнее остальных. Есть пять ситуаций, в которых конструктор не «немного хуже», а неприменим, и мы отговариваем от него заказчиков независимо от размера бюджета.
- Жёсткий SLA на отдельную операцию. Если задержка обработки в 30 секунд означает штраф или потерянную сделку, конструктор не подходит: очередь прогонов, ретраи и перезапуск платформы после обновления дают непредсказуемые задержки. Такие контуры пишутся кодом с явными гарантиями времени ответа.
- Финансовые операции без права на дубль и потерю. Списания, платёжные поручения, движения по складу с материальной ответственностью. Здесь нужна транзакционность, которой у конструктора нет: он выполняет шаги по очереди и не умеет откатывать уже сделанное.
- Требование доказуемого аудита. Отрасли, где надо предъявить проверяющему полный след: кто, когда, на основании чего изменил запись, и доказать, что след не редактировался. История прогонов в конструкторе для этого не предназначена, а в облачной платформе ещё и хранится ограниченный срок.
- Персональные данные особых категорий. Сведения о здоровье, биометрия, паспортные данные в теле запроса. Через облачный конструктор такие поля не пропускают вообще: передают ссылку на защищённое хранилище, а сопоставление делают внутри своего контура.
- Процесс, остановка которого останавливает бизнес. Приём заказов на производстве, отгрузка со склада, регистрация пациентов. Не потому, что конструктор часто падает, а потому, что при падении вы зависите от чужой площадки и чужих сроков восстановления, и повлиять на них не можете ничем.
Во всех пяти случаях правильный ответ не «поставьте n8n получше», а один из трёх: написать сервис, доработать учётную систему штатными средствами или оставить шаг человеку. Последний вариант обсуждают реже всего, а он часто выигрывает: операция, которая случается четыре раза в месяц и требует решения, дешевле стоит в исполнении сотрудника, чем в поддержке сценария, который эту операцию имитирует.
Таблица-сравнение из пяти строк, две колонки. Слева стоп-сигнал: жёсткий SLA на операцию, финансовые операции без права на дубль, требование доказуемого аудита, персональные данные особых категорий, процесс, остановка которого останавливает бизнес. Справа рекомендация: собственный сервис с гарантией времени ответа, транзакции в учётной системе, журнал аудита в своём контуре, ссылка вместо содержимого, свой контур с управляемым восстановлением. Внизу отдельная строка: «Операция реже 4 раз в месяц — оставить человеку».
И последнее, что стоит держать в голове при чтении любых материалов о конструкторах, включая этот. Конструктор — не архитектура, а инструмент сборки. Он не решает, какие процессы у вас есть, где источник правды по клиенту и что делать при расхождении данных. Если эти вопросы не решены, конструктор ускорит движение, но не изменит направление: вы получите тридцать быстрых сценариев поверх процесса, который работал плохо и в ручном виде. Порядок обратный — сначала карта процесса и данные, потом сборка. Мы разбирали, что именно надо привести в порядок до внедрения, в отдельном материале, и этот этап стоит дешевле любого из двенадцати сценариев в таблице.
Конструктор надёжен ровно до той точки, где вы перестаёте уметь повторить прогон и проверить результат.
