Примеры воркфлоу n8n: разбор реальных сценариев

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

Синхронизация данных между системами

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

Наивный вариант. По расписанию забрать всё из источника и записать в приёмник. Работает на сотне записей и разваливается на десяти тысячах.

Как правильно:

• Забирать только изменённое по отметке времени. Отметка хранится между запусками и обновляется после успешной обработки, а не до неё.
• Сверять по устойчивому идентификатору. Повторный запуск должен обновить запись, а не создать вторую. Это главное свойство, которого не бывает в шаблонах.
• Порциями. Забрать за раз всё - это выполнение на десятки минут и огромная запись в истории.
• Обновлять отметку только при успехе. Иначе сбой в середине означает потерянные записи, о которых вы не узнаете.

Самая частая ошибка здесь - отсутствие защиты от повтора. Сценарий отработал наполовину, вы перезапустили его, и половина записей продублировалась.

Обработка входящих заявок

Задача. Заявка с сайта или из формы попадает в CRM, ответственный получает уведомление, клиент - подтверждение.

Структура. Вебхук как триггер, проверка данных, запись в CRM, две отправки.

Что делает его рабочим:

• Проверка входных данных до всего остального. Пустое поле, спам, неверный формат - это отдельная ветка, а не падение воркфлоу.
• Быстрый ответ вебхуку. Отвечайте сразу, а не после всей обработки: отправитель не должен ждать, пока вы сходите в три системы.
• Секрет в запросе. Публичный адрес найдут сканеры. Проверка секрета - первая нода, до любых действий.
• Порядок действий по важности. Сначала запись в CRM, потом уведомления. Если упадёт уведомление, заявка уже сохранена.
• Обработка сбоя отправки. Клиент не получил подтверждение - об этом надо узнать, а не потерять молча.

Отчёты по расписанию

Задача. Каждое утро собрать цифры и отправить в чат или на почту.

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

Что стоит предусмотреть:

• Часовой пояс. По умолчанию UTC, и «каждый день в 9:00» окажется девятью утра по UTC - см. триггеры.
• Поведение при отсутствии данных. Пустой отчёт лучше, чем упавший воркфлоу: вы увидите, что данных нет, а не что автоматизация сломалась.
• Расчёты на стороне источника. База посчитает агрегаты быстрее, чем нода с кодом на выгруженных строках.
• Уведомление о сбое. Отчёт, который не пришёл, замечают через неделю. Отдельный сценарий на ошибку решает это - см. обработку ошибок.

Что общего у рабочих воркфлоу

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

1. Идемпотентность. Повторный запуск безопасен. Это первое, что стоит проверять в своём воркфлоу.
2. Явная обработка ошибок. Не «упадёт и остановится», а известная реакция на сбой.
3. Ограниченный объём. Порции и лимиты вместо «забрать всё».
4. Проверка входных данных. До действий, а не после.
5. Понятные имена нод. Через полгода вы будете читать этот сценарий как чужой, а выражения ссылаются на ноды по именам.

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

Готовые сценарии как отправная точка - шаблоны n8n. Сценарии с моделью - агентные разборы. Обзор - гид по n8n.