Форма как настоящий trigger

В прошлом уроке мы научились читать JSON в панели Output и обращаться к полям item через expressions. Но данные тогда появлялись в workflow потому, что мы сами нажимали «Execute» вручную. Теперь переходим к другой модели: workflow запускается не по кнопке, а по реальному событию — кто-то заполнил и отправил форму.

n8n Form Trigger: форма как источник событий

Manual Trigger — это кнопка «запусти прямо сейчас». Он удобен для отладки, но бесполезен в продакшне: никакой пользователь не зайдёт в редактор n8n и не нажмёт за вас Execute.

Form Trigger работает иначе. Он генерирует публичную HTML-форму с уникальным URL и переходит в режим ожидания. Как только кто-то заполняет эту форму и нажимает «Submit», n8n автоматически получает данные, упаковывает их в один item и запускает весь workflow — без каких-либо ручных действий с вашей стороны.

Главное отличие здесь не в интерфейсе, а в природе события. Manual Trigger реагирует на ваш клик внутри редактора. Form Trigger реагирует на внешнее событие — HTTP-запрос, который браузер пользователя отправляет при сабмите формы. Это делает его настоящим триггером в смысле автоматизации: workflow начинает работу сам, когда для этого есть повод.

При этом Form Trigger — это всегда стартовый узел. Он не может стоять в середине цепочки: именно он инициирует выполнение и передаёт первый item дальше по workflow. Данные, которые пользователь вводит в поля формы, становятся ключами и значениями этого item — и уже в следующем узле к ним можно обращаться через expressions так же, как к любому другому JSON.

Как отправка формы становится item в n8n.

Настройка полей формы: типы, метки и обязательность

Каждое поле формы в n8n Form Trigger определяется тремя параметрами, и между ними есть прямая связь с тем, что окажется в JSON item после отправки.

Field Label — это не просто подпись для пользователя. Именно это значение становится ключом в JSON item. Если вы написали «Описание проблемы», то в item появится ключ Описание проблемы, и именно к нему нужно обращаться в expressions: {{ $json['Описание проблемы'] }}. Никакой нормализации или переименования n8n не делает — что написали, то и получили.

Field Type определяет, какой тип ввода видит пользователь:

• text — обычная строка
• number — поле с числовым вводом (HTML рендерит <input type="number">); значение в JSON item приходит как строка, а не как число — если планируете числовые операции в expressions, приводите тип явно: {{ Number($json['Количество']) }}. Всегда проверяйте фактический тип значения в панели Output, прежде чем писать арифметику.
• email — строка с валидацией формата на стороне браузера
• dropdown — выбор из предзаданного списка вариантов

Required — флаг обязательности. Если поле помечено как Required, форма не отправится, пока оно не заполнено. Если не помечено — пользователь может оставить его пустым, и тогда ключ в JSON item либо не появится совсем, либо придёт с пустой строкой в зависимости от типа поля. К этому поведению подробнее вернёмся в секции об ошибках.

Посмотрим, как это выглядит на конкретном примере. Форма настроена с тремя полями:

• «Имя» — тип text, Required
• «Email» — тип email, Required
• «Описание проблемы» — тип text, Required

После того как пользователь заполняет поля и нажимает Submit, n8n создаёт один item со следующей структурой:

{
  "Имя": "Алексей",
  "Email": "alex@example.com",
  "Описание проблемы": "Не работает вход"
}

Ключи совпадают с Field Label один в один. В следующем узле к значению «Имя» обращаются как {{ $json['Имя'] }}, к email — {{ $json['Email'] }}. Это тот же механизм expressions из предыдущего урока, просто теперь ключи определяет конфигурация формы, а не вы вручную.

Практический вывод: называйте поля сразу так, как вам удобно на них ссылаться в expressions. Пробелы и кириллица работают, но их придётся оборачивать в квадратные скобки. Если планируете активно использовать поле в expressions, латинское имя без пробелов (name, email, description) сделает код чище.

Пошаговая настройка и тестовый запуск формы

Разберём весь путь от пустого canvas до данных в Output — от добавления узла до момента, когда видите заполненный item.

Создание узла и базовые настройки

Откройте новый workflow и нажмите «+» в центре canvas. В поиске наберите «Form» — среди типов триггеров появится n8n Form Trigger. Выбирайте его. Внутри настроек узла первым делом задайте заголовок формы (Form Title) — это то, что пользователь увидит над полями. После этого добавляйте поля через кнопку Add Field: для каждого поля указываете Field Label, Field Type и при необходимости флаг Required. Для тестовой формы заявки добавьте три поля: «Имя» (text, Required), «Email» (email, Required), «Описание проблемы» (text, Required). Сохраните настройки.

Предварительный просмотр формы

После сохранения в настройках узла появляется ссылка на Preview. Откройте её в браузере — убедитесь, что все три поля отображаются, а рядом с каждым стоит маркер обязательности. Это проверка конфигурации до запуска: если что-то не так с лейблами или типами, исправляете здесь, не тратя время на повторные отправки.

Тестовый режим: как n8n ждёт данные

В правом верхнем углу редактора переключите workflow в режим Test (не нажимайте Activate — это разные вещи). Затем кликните по узлу Form Trigger и нажмите кнопку Listen for test event. С этого момента n8n открывает «окно ожидания»: он слушает ровно одну входящую отправку формы. Пока окно открыто, вернитесь к Preview-ссылке формы в браузере, заполните поля и нажмите Submit. N8n получает данные, закрывает окно ожидания и сразу отображает результат в панели Output узла.

Что проверять в Output

После успешной отправки узел Form Trigger окрасится в зелёный. Откройте панель Output и переключитесь на вкладку JSON — убедитесь, что items показывает ровно 1 запись, а не 0 и не несколько. Это подтверждает, что данные пришли именно из текущей отправки, а не из кэша предыдущего запуска. Структура самого item — ключи и значения — соответствует тому, что разобрали в предыдущей секции.

Тестовый режим vs активный workflow

Важно понимать разницу между двумя режимами работы:

• В тестовом режиме (Listen for test event) n8n ждёт ровно одну отправку, показывает результат в редакторе и останавливается. Идеален для проверки конфигурации.
• В активном режиме (кнопка Activate в правом верхнем углу) workflow работает непрерывно: каждая отправка формы автоматически запускает полный прогон без вашего участия. Это продакшн-поведение.

Для первого тестового запуска активировать workflow не нужно — тестовый режим полностью достаточен, чтобы убедиться, что данные приходят и структура item соответствует ожиданиям.

Типичные ошибки: потерянная отправка и пустые поля

Две ошибки здесь встречаются настолько часто, что стоит разобрать их отдельно — не как теорию, а как конкретные симптомы и способы исправления.

Отправка формы до нажатия «Listen for test event»

Если открыть Preview-ссылку, заполнить поля и нажать Submit раньше, чем редактор перешёл в режим ожидания, — данные просто уйдут в никуда. n8n не буферизует пропущенные отправки: он принимает только те, что пришли пока окно ожидания было открыто.

Признак прост: после отправки формы узел Form Trigger не окрасился в зелёный, панель Output пуста или показывает предыдущий результат. Решение — нажать «Listen for test event» ещё раз и повторно отправить форму. Повторная отправка безопасна: тестовый режим каждый раз ждёт ровно одну новую запись и перезаписывает Output.

Необязательное поле: отсутствующий ключ вместо пустой строки

Если поле не помечено как Required и пользователь оставил его пустым, поведение n8n неочевидно. Представим, что к форме добавили необязательное поле «Телефон» (тип text, без Required), а пользователь его не заполнил.

Многие ожидают увидеть в Output пустую строку для незаполненного поля:

{
  "Имя": "Алексей",
  "Email": "alex@example.com",
  "Описание проблемы": "Не работает вход",
  "Телефон": ""       ← ожидаемое поведение
}

Но реальный Output выглядит иначе — ключа Телефон нет совсем:

{
  "Имя": "Алексей",
  "Email": "alex@example.com",
  "Описание проблемы": "Не работает вход"
  ← ключа «Телефон» не существует
}

Это не пустая строка, а полное отсутствие ключа. Если в следующем узле написать {{ $json['Телефон'] }}, результатом будет undefined. Для большинства узлов это не вызовет видимой ошибки сразу, но если дальше по цепочке будет операция над этим значением (например, .trim() или числовое сравнение), workflow упадёт с ошибкой.

Защититься можно двумя способами: либо помечать поля как Required, если данные действительно нужны, либо в expression явно обрабатывать отсутствие ключа:

{{ $json['Телефон'] ?? 'не указан' }}

Оператор ?? вернёт правую часть, если левая — undefined или null. Это минимальная страховка для необязательных полей, которые всё же участвуют в дальнейшей обработке. В следующем уроке разберём нормализацию и валидацию данных из формы подробнее — там этот паттерн встретится снова.