Заявку из формы нужно проверить, передать в CRM и включить в отчёт. n8n помогает связать эти действия в одну автоматизацию. Вы собираете цепочку узлов, а данные проходят по ней без ручного копирования. Начать можно с простого сценария, постепенно добавляя приложения и условия.
Начнём с учебного сценария без внешних аккаунтов: зададим вымышленную запись, проверим условие и разделим результат по веткам. Затем разберём облако, свой сервер, повторы, ИИ и ограничения. Так будет понятнее, где заканчивается демонстрация и начинается поддержка рабочей автоматизации.
Что такое n8n и кому подходит
n8n представляет собой платформу автоматизации рабочих процессов. Сценарий собирается из узлов, соединённых на холсте, а данные проходят между ними. Платформа подходит для интеграций, обработки информации и повторяемых операций, если у задачи есть понятные входы, правила и ожидаемый результат.
Например, форма отправляет заявку, n8n проверяет название услуги и создаёт черновик в CRM, системе учёта клиентов. Для обмена программы используют API: правила запросов и ответов. Если обязательное поле пустое, сценарий может направить запись ответственному на разбор.
Платформу часто относят к low-code: базовые действия доступны визуально, но нестандартные условия могут потребовать выражений, кода и работы с API. Поэтому «без программирования» лучше понимать как возможность начать с простых задач. Она не отменяет технической сложности интеграции.
В управлении проектами такие сценарии часто связаны с рутинными передачами и уведомлениями. Контекст разобран в статье про автоматизацию и изменения в управлении проектами. Перед сборкой полезно описать сам процесс, включая исключения и ответственного за сбои.
Как устроен workflow в n8n
Workflow является схемой выполнения: узлы задают действия, соединения передают данные и определяют дальнейший путь. Триггер отвечает за начало, а выполнение показывает конкретный запуск с его входами и результатами. Одинаковая схема может запускаться много раз на разных данных.
| Понятие | Значение | Пример |
|---|---|---|
| Workflow | Сценарий из связанных узлов | Проверка входящей записи и выбор ветки |
| Node | Узел с действием или логикой | Изменить поля, сравнить значение, обратиться к API |
| Trigger | Условие начала выполнения | Ручной запуск, расписание или входящее событие |
| Item | Отдельный элемент данных в потоке | Одна заявка с её полями |
| Expression | Вычисляемое значение вместо постоянного | Взять статус из текущего элемента |
| Execution | Конкретное выполнение сценария | Запуск с выбранной записью и его результаты |
| Credentials | Настройки доступа к подключаемому сервису | Разрешённое подключение к отдельной учебной системе |
После каждого узла смотрите вход и выход: какие поля пришли и что передаётся дальше. Соединение на холсте не помешает отправить строку вместо числа или потерять идентификатор заявки.
Различайте описание сценария и выполненный запуск. Схема показывает намерение, а журнал выполнения помогает выяснить, что произошло на конкретных данных. Успешный тест одного случая не подтверждает работу на пустом поле, повторном событии или временном отказе сервиса.
Триггер выбирают по источнику события. Расписание запускает регулярную проверку, а webhook принимает событие от другого сервиса по специальному адресу. Для обучения удобен ручной триггер: вы сами начинаете выполнение и смотрите результат. Для расписания отдельно задайте часовой пояс.
Облако или собственный сервер
В облачном варианте часть инфраструктурных задач выполняет провайдер. При самостоятельном размещении команда отвечает за установку, обновления, доступ и восстановление. Выбор зависит от требований к данным, возможностей поддержки и условий использования. Свой сервер не делает автоматизацию бесплатной и безопасной автоматически.
| Вопрос | Облачный вариант | Самостоятельное размещение |
|---|---|---|
| Кто поддерживает среду? | Значительная часть инфраструктуры у провайдера | Команда или выбранный администратор |
| Что учитывать в расходах? | Тариф, ограничения и подключаемые сервисы | Сервер, сопровождение, резервирование и внешние API |
| Где проходят данные? | Через облачную среду и выбранные интеграции | Через вашу среду и все подключённые внешние сервисы |
| Что проверить до выбора? | Доступность, условия, лимиты и функции плана | Требования эксплуатации, лицензии и компетенции поддержки |
Исходный код n8n доступен, но модель лицензирования имеет ограничения. В официальной документации описаны Sustainable Use License и Enterprise License на основе fair-code. Поэтому называть платформу безусловно свободной для любого коммерческого использования некорректно.
Для внутренней автоматизации, клиентского продукта и предоставления доступа третьим лицам могут действовать разные условия. Перед выбором коммерческой модели прочитайте актуальную лицензию и пояснения поставщика. Не переносите вывод о разрешённом личном упражнении на продажу собственного сервиса.
Самостоятельное размещение означает контроль над средой, но внешние узлы всё равно отправляют данные выбранным сервисам. Если сценарий обращается к облачной модели, часть информации покидает сервер. Карту передачи данных нужно составлять по всей цепочке.
Локальный запуск означает, что n8n работает на вашем компьютере, а редактор открывается в браузере. Компьютер должен оставаться включённым для выполнения сценариев. Для первого упражнения подойдёт и облачный редактор; сервер нужен, когда вы готовы отвечать за его установку и поддержку.
Первый сценарий без внешних аккаунтов
Соберём проверку учебной заявки: ручной запуск, исходные данные, очистка значений и условие. Подходящая запись получит пометку «К обработке», остальные «На разбор». Подключать почту и CRM не потребуется: результат будет виден в редакторе n8n.
Создайте запись и соедините узлы
Создайте пустой workflow и добавьте Manual Trigger. Следом поставьте Edit Fields, который также называют Set. Соедините выход триггера со входом Edit Fields. В настройке Mode выберите Manual Mapping и через Add Field добавьте поля из таблицы, у каждого тип String, то есть строка.
| Name: имя поля | Value: исходное значение | Что оно означает |
|---|---|---|
| request_id | demo-1 | Идентификатор учебной заявки |
| subject | Проверить черновик | Обязательная тема заявки |
| status | New | Введите один пробел до и после New |
Для исходных значений используйте Fixed, постоянное значение. Запустите цепочку кнопкой Execute под холстом; в некоторых версиях она называется Execute Workflow. Откройте Edit Fields и посмотрите OUTPUT: там должны быть идентификатор, тема и исходный статус одной записи.
Очистите значения перед проверкой
После первого Edit Fields добавьте второй и соедините их. Задайте те же имена полей, но в Value переключитесь на Expression, вычисляемое значение. Выражения ниже убирают пробелы по краям; для статуса также меняют буквы на строчные.
| Поле | Выражение в Value | Ожидаемое значение |
|---|---|---|
| request_id | {{ String($json.request_id ?? '').trim() }} | demo-1 |
| subject | {{ String($json.subject ?? '').trim() }} | Проверить черновик |
| status | {{ String($json.status ?? '').trim().toLowerCase() }} | new |
$json обозначает данные текущей записи. Часть ?? '' подставляет пустую строку, если поля нет или оно равно null, специальному значению «нет данных». После нового запуска откройте OUTPUT второго узла: пробелы в статусе должны исчезнуть, значение станет new.
Это упражнение для текстовых полей. Преобразование через String не проверяет, что пришёл именно текст: оно превращает в строку и число, и объект. В рабочем сценарии допустимые типы проверяют до такой очистки, если от них зависит правильность записи.
Настройте условие и две ветки
Добавьте If после узла очистки. Через Add condition задайте три условия типа String из таблицы. Между ними выберите AND: запись проходит, только когда выполнены все условия. Здесь мы принимаем новые заявки с заполненными идентификатором и темой.
| Значение слева: Expression | Сравнение | Значение справа: Fixed |
|---|---|---|
{{ $json.request_id }} | is not empty | Не требуется |
{{ $json.subject }} | is not empty | Не требуется |
{{ $json.status }} | is equal to | new |
К выходу true подключите Edit Fields с полем route и значением «К обработке». К false подключите такой же узел со значением «На разбор». Сохраните исходные поля: в Include in Output выберите All Input Fields. Если вместо этого есть опция Keep Only Set Fields, выключите её.
Запустите весь workflow заново. Откройте узел на сработавшей ветке и проверьте OUTPUT: у записи должны сохраниться тема, идентификатор, очищенный статус и поле route. Если ничего не появилось, сначала проверьте соединения и результат узла перед If.
| Изменение в исходной записи | Ожидаемый путь | Что проверяем |
|---|---|---|
Статус New , остальные поля заполнены | true, «К обработке» | Очистка пробелов и регистра |
| Тема состоит из пробелов | false, «На разбор» | Проверка после очистки |
| Удалено поле subject | false, «На разбор» | Отсутствующее поле становится пустой строкой |
| Статус done | false, «На разбор» | Запись не соответствует условию новой заявки |
Для каждого случая меняйте первый узел с данными и выполняйте весь сценарий заново. Чтобы проверить отсутствие поля, удалите его целиком, а не только сотрите значение. Повтор с тем же идентификатором снова проверит заявку: эта схема пока не хранит историю и не удаляет дубли.
Как передавать и преобразовывать данные
До подключения договоритесь о полях: как называются, что означают и какие обязательны. Например, у заявки нужен идентификатор, чтобы найти её после передачи в другую систему. В каждом узле смотрите, сохранилось ли это поле и относится ли оно к нужной записи.
Форма передаёт full_name, а CRM ожидает name. В Edit Fields создайте поле name и возьмите значение из full_name. Если имя обязательно, сначала проверьте его после удаления пробелов. Пустую запись направьте на разбор, а не дополняйте вымышленным именем.
Пустая строка означает, что текст не введён; отсутствующее поле вообще не пришло, а null обычно обозначает отсутствие значения. Иногда их можно обработать одинаково, как в учебном сценарии. Если причины важны для бизнеса, сохраните отдельную пометку, прежде чем приводить их к одному виду.
Число 5 и строка "5" выглядят похоже, но для программы это разные типы. Перед расчётом преобразуйте значение в число и обработайте ошибку. Для даты дополнительно проверьте формат и часовой пояс, а для суммы единицы измерения.
Несколько элементов требуют отдельной проверки. Успешная обработка одной задачи не доказывает правильность списка. Убедитесь, что идентификаторы не перемешались, нужные поля сохранились и ветвление применяется к каждому элементу в ожидаемом порядке.
Как подключать приложения и API
Сначала проверьте готовый узел нужного сервиса и доступные операции. Если подходящего действия нет, может понадобиться HTTP-запрос по официальному API. Для подключения нужны разрешение владельца, минимальные права и понимание того, какие данные уйдут во внешнюю систему.
Credentials, учётные данные подключения, храните в предназначенной для них настройке n8n. Используйте отдельный учебный доступ с нужными правами. Токен или пароль не стоит записывать в название узла: он может попасть в скриншот или экспорт схемы.
В документации API найдите способ доступа, обязательные поля, ограничения частоты и формат ошибок. Успешный HTTP-ответ сообщает об обмене, но результат самой операции может находиться внутри ответа. Например, сервис принял запрос, а создание записи ещё продолжается: проверьте её конечный статус.
Начните с чтения разрешённых тестовых данных. Затем подготовьте запись в черновик или изолированную систему, если такой режим доступен. Отправка сообщения реальному человеку, изменение заказа и создание платежа требуют отдельного согласования и контроля последствий.
Для входящего webhook продумайте, кто может его вызвать и как проверяется источник. Случайно сложный адрес не заменяет подходящую защиту. Не публикуйте рабочую точку входа и не пересылайте реальные примеры с секретами ради удобства учебного материала.
У интеграции есть владелец с обеих сторон. Уточните, кто сообщит об изменении полей, истечении доступа и отключении сервиса. Иначе исправный workflow может перестать работать после изменения внешней системы, хотя саму схему никто не трогал.
Примеры автоматизаций для работы
Выбирайте повторяемую задачу с понятным входом и результатом. Для первого рабочего сценария удобно сначала готовить черновик или список действий, который проверяет человек. В таблице показано, что передать по цепочке и как заметить частые сбои.
| Задача и вход | Ожидаемый выход | Ошибка или повтор |
|---|---|---|
| Заявка: ID lead-demo, услуга «Диагностика», город N | Черновик CRM с тем же ID и нужным направлением | Нет услуги: на разбор. Такой ID уже есть: проверить существующую запись перед созданием |
| Отчёт: дата и данные обращений по каналам | Сводка за согласованный период с отметкой времени загрузки | Один источник недоступен: отметить неполноту, а не показать пропуск как ноль |
| Напоминание: ID задачи, срок и ответственный | Список просроченных задач для ответственного | Повтор запуска не создаёт второе одинаковое напоминание по принятому правилу |
| Текст обращения из разрешённого источника | Предложенная категория и черновик ответа | Не хватает сведений: ручной разбор вместо уверенного выбора отдела |
| Две версии справочника с идентификаторами | Список добавленных и изменённых записей | Не совпали ID: показать расхождение до перезаписи данных |
В отчёте сначала согласуйте определения показателей. Если рекламный кабинет считает клики на телефон, а CRM состоявшиеся разговоры, это разные события. Подготовку общей методики разбираем в статье про маркетинговый дашборд.
Для напоминаний выберите правило: при первом нарушении срока, каждый день или после смены ответственного. Храните сведения об отправке так, чтобы следующий запуск мог их проверить. Количество выполнений само по себе не покажет пользу: сравните ручные действия и время на разбор ошибок.
Как обрабатывать ошибки и повторы
Рабочий сценарий должен различать временный сбой, неверные данные и уже выполненное действие. Повтор помогает не всегда: после частично успешной операции он может создать дубль. Для каждого внешнего изменения нужен понятный способ определить, произошло ли оно.
Представим: CRM создала запись, но ответ потерялся. Повтор может создать дубль. Некоторые API поддерживают идемпотентный запрос: повтор с тем же ключом не выполняет действие заново. Если такой функции нет, ищите результат по стабильному идентификатору и учитывайте параллельные запросы.
| Ситуация | Разумная обработка | Опасное упрощение |
|---|---|---|
| Недопустимые данные | Сохранить причину и отправить на разбор | Бесконечно повторять тот же запрос |
| Временная недоступность | Ограниченный повтор по правилам сервиса | Повторять без ограничений и учёта частоты |
| Неясен результат записи | Проверить факт действия по стабильному идентификатору | Сразу создать новую запись |
| Истёк доступ | Сообщить владельцу и восстановить разрешённое подключение | Расширить права всем участникам |
| Повторное событие | Определить, обработано ли оно ранее | Считать каждый вход новым бизнес-действием |
В n8n можно настроить error workflow, отдельную цепочку для сообщения об ошибке. Она начинается с Error Trigger. Передайте ответственному название сценария, шаг сбоя и идентификатор записи, чтобы он нашёл нужное выполнение. Уже выполненные внешние действия такая цепочка не отменяет.
Посмотрите, что остаётся в журнале выполнения: вход, промежуточные данные, ответ сервиса. Это помогает диагностике, но может создавать лишние копии информации. Определите доступ и срок хранения, а в оповещение передавайте только необходимое для разбора.
Перед повтором найдите последний завершённый шаг. Если запись уже появилась в CRM, продолжать нужно с её идентификатором. Если создать запись не удалось, можно повторить создание по согласованному правилу. Так восстановление опирается на результат операции, а не только на красный узел.
Для проверки подготовьте обычную заявку, запись без обязательного поля и повтор того же события. Отдельно разберите недоступность сервиса: кто узнает об ошибке и как найдёт необработанную запись? Эти случаи показывают границы автоматизации лучше, чем один успешный запуск.
Что меняется при добавлении ИИ
ИИ-узел добавляет вероятностный результат к обычному потоку данных. Модель может неправильно классифицировать текст, пропустить условие или вернуть неподходящий формат. Поэтому проверка должна охватывать не только соединение узлов, но и качество ответа на разных примерах.
Для классификации обращения определите разрешённые категории и путь для неуверенного результата. Не заставляйте модель всегда выбирать отдел, если данных недостаточно. Отдельная очередь разбора лучше ошибочной автоматической отправки в неподходящий процесс.
Свободный текст из письма или страницы не должен становиться инструкцией к выполнению действий. Его содержание может включать посторонние команды. Разведите входные данные и полномочия сценария, ограничьте инструменты и проверяйте результат перед внешним изменением.
Запрос к внешней модели может стоить денег и передавать данные провайдеру. Учтите лимиты, размер текста и повторные обращения. Даже при собственном сервере эти вызовы остаются внешними, если вы выбрали облачного поставщика модели.
Сначала используйте ИИ для черновика, который проверяет человек. Для аналитических задач полезно сравнить подход с материалом о проверке AI-результатов при работе с данными. Наличие связного ответа не подтверждает правильность вычислений и выводов.
Как безопасно поддерживать автоматизацию
У сценария должны быть владелец, описание, правила изменения и способ остановки. Автоматизация продолжает действовать после того, как автор закрыл редактор. Поэтому важно понимать, кто заметит сбой и кто может приостановить выполнение до появления новых последствий.
Разделяйте учебную и рабочую среду. Проверка новой логики не должна отправлять настоящие уведомления или менять заказы. Если у сервиса нет отдельного тестового режима, ограничьте упражнение локальными данными и согласуйте безопасный вариант проверки.
Перед обновлением сохраните схемы, настройки и данные, затем проверьте восстановление на отдельной среде. Назначьте ответственного за обновление сервера и подключений. Так после сбоя команда сможет вернуть работу, даже если автор сценария недоступен.
После переименования поля проверьте узлы, которые его читают. Например, вместо status пришло state: условие перестанет видеть значение. Сохранённый набор учебных записей поможет повторить такие случаи после изменения схемы и найти, где нужно обновить сопоставление.
Пересматривайте права подключений и доступ участников. Сценарий, которому нужно читать таблицу, не должен получать лишние возможности ради удобства. При уходе автора команда должна сохранить управляемый доступ без передачи личных паролей.
Что требуют в вакансиях с n8n
На HireHi n8n упоминают 166 открытых вакансий на русском. Больше всего их в разработке: 66, или 40%. Дальше идут маркетинг (32), управление проектами и продуктом (22), DevOps и администрирование (21), аналитика (15). Самая частая роль: AI-инженер, 37 вакансий.
Отдельной профессии «специалист по n8n» рынок почти не знает. Работодатели перечисляют n8n рядом с API, моделями ИИ и языком программирования, а Make часто указывают как равноценную замену. В таблице доля вакансий, где навык назван в тексте.
| Что упоминают рядом с n8n | Вакансий | Доля |
|---|---|---|
| Модели ИИ: LLM, GPT, Claude, нейросети | 118 | 71% |
| API и REST | 113 | 68% |
| Python | 93 | 56% |
| ИИ-агенты | 73 | 44% |
| SQL и базы данных | 67 | 40% |
| Make | 66 | 40% |
| CRM, из них amoCRM и Битрикс24 в 37 вакансиях | 65 | 39% |
| RAG, поиск по базе знаний | 45 | 27% |
| Git | 43 | 26% |
| JavaScript или TypeScript | 41 | 25% |
| Docker | 40 | 24% |
| Английский | 33 | 20% |
| Вебхуки | 32 | 19% |
| Zapier | 18 | 11% |
По грейдам больше всего middle: 76 вакансий, 46%. Senior 58 (35%), lead и head 18 (11%), junior и стажёров 14 (8%). Удалённых вакансий 90, это 54%; остальные в офисе или гибриде, чаще всего в Москве. Стаж в годах назван в 64 вакансиях, чаще всего от 3 лет.
Навык n8n встречается в разных ролях: интеграции, операции, аналитика и маркетинг. Это инструмент, а не единая профессия с одинаковыми обязанностями. На HireHi для поиска по навыку введите +n8n. Сопоставляйте кейс с требованиями вакансий с навыком n8n и объясняйте, какую задачу решает ваш сценарий.
Даже в junior-вакансии n8n может стоять только в блоке «будет плюсом». В примере ниже основное требование составляют REST API, вебхуки, JSON, секреты вне кода и минимальные права. В плюсах названы обработка ошибок, повторы и человек в контуре: те же темы, что разобраны выше.
Как показать n8n в портфолио
Покажите, какие действия связывает сценарий и что происходит с одной записью. К схеме добавьте пример входа, результат и разбор ошибки. Например: пустая тема ушла на разбор, а повтор заявки не создал вторую запись. Указывайте только выполненные проверки.
Для учебной проверки покажите исходные поля, их очистку и обе ветки. Затем опишите, как подключили бы источник заявок и CRM. Отдельно отметьте, где потребуется сохранять уже обработанные идентификаторы: в нашем упражнении такой памяти ещё нет.
Если прикладываете экспорт, проверьте его на секреты, рабочие адреса и закрытые данные. Подготовьте вымышленные примеры и инструкцию воспроизведения. Не публикуйте историю реальных выполнений с контактами клиентов ради доказательства опыта.
Для задач с кодом и API полезно сравнить требования к Python-разработчикам. Это смежное направление: наличие n8n и конкретный состав интеграций нужно уточнять в описании позиции.
