Если одинаковая проверка заказов повторяется в нескольких схемах n8n, её можно вынести в один отдельный workflow. Родитель передаёт данные, дочерняя схема проверяет их и возвращает результат. Разберём этот путь с Execute Sub-workflow: создадим два workflows, свяжем их и проверим, что изменение дочерней проверки действительно видно родителю.
Результат инструкции
В родительской схеме три вымышленных заказа превращаются в отдельные items и уходят в Reusable Order Check. Дочерний workflow очищает поля, проверяет суммы и повторяющиеся ID, добавляет validation_version: v1. Родитель получает все три результата: O1 и O2 идут в Ready Orders, O3 — в Input Review. При технической ошибке вызов останавливается, а не выдаёт заказ за готовый.
В примере нет AI-модели, API-ключей и внешних отправок. Мы учимся повторно использовать проверку данных. Статусы видны в данных выполнения n8n; отдельного постоянного журнала или уведомления оператору схема не создаёт.
Что понадобится
- Работающий n8n и права создавать, изменять и публиковать свои учебные workflows. Тест выполнен на n8n 2.42.4.
- Два новых workflows в одном доступном вам проекте: дочерний Reusable Order Check и родительский Parent Order Check. Не импортируйте поверх рабочих схем.
- Файлы для импорта ниже либо ручная сборка. Все данные вымышленные; в JSON нет credentials, расписания и Webhook.
Если n8n ещё не установлен: инструкция через Docker
Шаг 1. Импортируйте дочернюю схему
Скачать n8n-subworkflow-child.json
Сохраните файл, создайте новый workflow и выберите в меню редактора Import from File. Импортируйте n8n-subworkflow-child.json. Если браузер вместо скачивания показывает JSON, используйте «Сохранить как». Имя схемы — ezGPT - Reusable Order Check. На полотне должно быть три узла.
When Executed by Another Workflow → Validate Orders → Return ResultПервый узел — Execute Sub-workflow Trigger, второй — Code, третий — Edit Fields (Set). Если собираете вручную, добавьте именно три узла и соедините их слева направо. Manual Trigger в дочерней схеме не нужен: вход поступит из родителя.
Шаг 2. Укажите, как дочерняя схема принимает данные
Откройте When Executed by Another Workflow. В Input data mode выберите Accept all data. Это передаст входные items в наш Code без автоматического отбора полей. Важно: режим не доказывает, что данные верны. Проверка обязательных полей находится в следующем узле.
В Settings самого workflow проверьте This workflow can be called by. Для учебной пары используйте доступный вариант, допускающий вызов из того же проекта, без открытия вызова всем workflows организации. Если родитель не видит дочернюю схему, сначала проверьте проект и свои права; не меняйте чужие permissions ради примера.
Шаг 3. Настройте проверку заказов
В Validate Orders выберите Language: JavaScript и Mode: Run Once for All Items. Вставьте полный код ниже. В импортированном файле он уже есть. Это та же проверка, которую мы раньше собирали в одном workflow; теперь она живёт отдельно.
Показать код (32 строк)
const items = $input.all();
const clean = value => typeof value === 'string'
? value.trim().replace(/\s+/g, ' ') : '';
const ids = items.map(item => clean(item.json.order_id));
const counts = new Map();
for (const id of ids) counts.set(id, (counts.get(id) ?? 0) + 1);
return items.map((item, index) => {
const row = item.json;
const order_id = ids[index];
const client = clean(row.client);
const currency = clean(row.currency).toUpperCase();
const raw = row.amount_minor;
const amount_minor = typeof raw === 'number' ? raw
: typeof raw === 'string' && /^\d+$/.test(raw.trim())
? Number(raw.trim()) : NaN;
const errors = [];
if (!order_id) errors.push('order_id_required');
if (order_id && counts.get(order_id) > 1) errors.push('duplicate_order_id');
if (!client) errors.push('client_required');
if (currency !== 'RUB') errors.push('currency_must_be_RUB');
if (!Number.isSafeInteger(amount_minor) || amount_minor < 0)
errors.push('amount_minor_invalid');
const json = { order_id, client, currency,
status: errors.length ? 'needs_review' : 'ready', errors };
if (!errors.length) {
json.amount_minor = amount_minor;
json.amount_rub = amount_minor / 100;
}
return { json, pairedItem: { item: index } };
});Вход — отдельные items с order_id, client, amount_minor и currency. amount_minor обозначает копейки. Код принимает безопасное неотрицательное целое число или строку из цифр, сохраняет допустимый ноль и отклоняет null. Повторяющиеся ID проверяются внутри одного входного набора. Истории предыдущих запусков у этой проверки нет.
Подробный разбор JavaScript и pairedItem
Шаг 4. Добавьте явную метку результата
Откройте Return Result. Это Edit Fields (Set) в режиме Manual Mapping. Добавьте поле validation_version, тип String, фиксированное значение v1. Включите Include Other Input Fields, чтобы сохранить status, errors и поля проверенного заказа. Соединение Validate Orders → Return Result обязательно.
{"validation_version":"v1"}Эта метка не является автоматической версией n8n. Она нужна для проверки нашего примера: если родитель её получил, данные дошли до последнего узла дочерней схемы. Не оставляйте в Return Result только одну метку без остальных полей: тогда родителю нечего будет проверять.
Шаг 5. Сохраните и опубликуйте дочерний workflow
Сохраните Reusable Order Check, исправьте предупреждения о незаполненных полях и нажмите Publish для этой учебной схемы. В версиях с переключателем активации используйте соответствующее действие, учитывая свою версию n8n. Дочерняя схема содержит только три описанных узла, без расписания, Webhook и действий во внешних системах.
В нашем n8n 2.42.4 обычный CLI-вызов использовал опубликованную дочернюю версию: неопубликованный workflow не выполнялся. Ручной запуск редактора может работать с черновиками иначе. Чтобы не смешивать эти случаи, эта инструкция использует явно опубликованную дочернюю схему; родитель остаётся ручным. После изменения дочернего workflow проверяйте, какую версию вызывает ваш режим выполнения.
Шаг 6. Импортируйте родительскую схему
Скачать n8n-subworkflow-parent.json
Создайте второй новый workflow и импортируйте n8n-subworkflow-parent.json. Название — ezGPT - Parent Order Check. Должны появиться семь узлов. Дочернюю схему не импортируйте в то же полотно: это два отдельных workflows в списке n8n.
Manual Trigger → Test Orders → Split Orders → Call Order Check → Ready Check
├ true → Ready Orders
└ false → Input ReviewВ Call Order Check намеренно оставлен CHILD_WORKFLOW_ID. Это не настоящий ID и не секрет. В шаге 9 вы выберете свою дочернюю схему; пока предупреждение этого узла ожидаемо. Родитель не публикуйте и не подключайте к боевому триггеру.
Шаг 7. Подготовьте три заказа в родителе
Откройте Test Orders: это Edit Fields (Set). В Mode: JSON Output вставьте объект ниже. Запустите узел: один item должен содержать поле orders с тремя записями. Никакие данные CRM не нужны.
{
"orders": [
{
"order_id": "O1",
"client": " Анна Петрова ",
"amount_minor": "150000",
"currency": "rub"
},
{
"order_id": "O2",
"client": "Борис",
"amount_minor": 0,
"currency": "RUB"
},
{
"order_id": "O3",
"client": "",
"amount_minor": "сумма",
"currency": "RUB"
}
]
}O1 должен пройти очистку и получить сумму 1500 рублей, O2 — пройти с нулевой суммой. У O3 нет имени и сумма не является числом: ожидаются client_required и amount_minor_invalid. Нулевые заказы разрешены только учебным правилом этого примера, не автоматически для любого бизнеса.
Шаг 8. Передайте отдельные записи, а не вложенный массив
В Split Orders укажите Field to Split Out: orders, Include: No Other Fields. Выполните цепочку до этого узла. На выходе должны быть три items, в каждом order_id и остальные поля находятся прямо в json. Если в Code попадёт один item с массивом orders, наш код не найдёт поля заказа на ожидаемом уровне.
Шаг 9. Выберите дочерний workflow и дождитесь результата
Откройте Call Order Check — это Execute Sub-workflow. Source: Database. В Workflow выберите From list и найдите ezGPT - Reusable Order Check. Такой выбор должен заменить CHILD_WORKFLOW_ID. Если используете ID, возьмите его из URL своей дочерней схемы после /workflow/, а не из скачанного файла.
Mode: Run once with all items. В Options включите Wait for Sub-Workflow Completion. Родитель должен дождаться проверенных записей, а не продолжить с непроверенным входом. В выбранном Accept all data отдельные поля Workflow Inputs не требуются: весь набор отправляется в дочернюю схему.
В Settings Call Order Check оставьте On Error: Stop Workflow. Не выбирайте Continue: исключение дочерней схемы не должно превращаться в обычный заказ. В этом примере не используйте Run once for each item — проверка дублей должна видеть записи вместе.
Шаг 10. Запустите родителя и проверьте оба результата
Сохраните Parent Order Check и выполните всю цепочку через Manual Trigger. В OUTPUT Call Order Check ожидаются три items. У всех должна быть validation_version v1. O1: ready, client «Анна Петрова», amount_minor 150000, amount_rub 1500. O2: ready, обе суммы 0. O3: needs_review, errors из двух причин, без денежных полей.
Ready Check сравнивает String-значение выражения ниже с обычным текстом ready через is equal to. Выход true соединён с Ready Orders, false — с Input Review. Эти последние узлы — No Operation, do nothing: они показывают записи, но никуда их не отправляют.
{{ $json.status }}В Ready Orders должно быть два items, в Input Review — один. Если n8n показывает View sub-execution в Call Order Check, откройте дочернее выполнение и сравните вход триггера с выходом Return Result. Доступность просмотра зависит от сохранения выполнений и вашей версии. Главное доказательство для упражнения — точные данные, вернувшиеся родителю.
Шаг 11. Проверьте неправильную сумму
В Test Orders родителя замените amount_minor у O1 на null. Повторите всю цепочку: O1 должен уйти в Input Review с amount_minor_invalid, O2 останется ready, O3 — needs_review. Затем восстановите исходный JSON. Не исправляйте null на 0 автоматически: отсутствие суммы и известная нулевая сумма — разные ситуации.
Шаг 12. Проверьте, что дубли видны между записями
В том же Test Orders замените order_id у O2 на « O1 » с пробелами. После очистки оба ID станут O1, и оба заказа должны получить duplicate_order_id. В Ready Orders не должно быть новых записей из этого запуска: третий заказ O3 тоже невалиден. Восстановите O2.
Если дубли проходят, проверьте Mode: Run once with all items в родителе и Code в дочерней схеме. Три отдельных вызова не дают общей картины набора. Эта проверка не ищет повторные отправки из прошлых запусков и не заменяет идемпотентность.
Шаг 13. Обновите дочернюю проверку без правки родителя
Откройте только Reusable Order Check. В Return Result поменяйте validation_version с v1 на v2, сохраните и снова опубликуйте новую версию. Код проверки не меняйте. Затем запустите Parent Order Check с исходными заказами: результаты должны остаться прежними, но каждый item должен содержать v2.
Если видите v1, проверьте выбранную дочернюю схему, её опубликованную версию и закреплённые данные. Не создавайте новую копию дочернего workflow ради каждой правки: родитель продолжит ссылаться на старый ID. Именно повторное использование одной схемы позволяет обновлять проверку централизованно.
Шаг 14. Проверьте техническую ошибку и восстановите схему
На этой учебной дочерней схеме временно замените код Validate Orders строкой ниже. Сохраните и опубликуйте изменение, затем запустите родителя. Execute Sub-workflow должен завершиться ошибкой; Ready Check и обе конечные ветки не должны получить новые результаты. Проверяйте текущее выполнение, а не старый OUTPUT успешного запуска.
throw new Error('training_child_error');Верните полный код из шага 3 и метку v1, сохраните и опубликуйте восстановленную дочернюю версию. Снова выполните родителя: два ready, один needs_review, validation_version v1. Дочернюю схему не вызывает кто-то ещё в этом упражнении; на общей рабочей проверке такой эксперимент делать нельзя. Если больше не продолжаете учебный пример, можете снять её с публикации — следующее выполнение родителя в опубликованном режиме тогда потребует повторного включения.
Если результат отличается
| Симптом | Причина | Что проверить |
|---|---|---|
| Workflow не найден | В файле оставлен шаблон ID | Выберите дочерний From list |
| Workflow is not active | Нет нужной опубликованной версии | Publish дочерней схемы |
| Возвращается только v1 | Остальные поля удалены | Include Other Input Fields |
| Нет проверенных статусов | Родитель не ждёт завершения | Wait for Sub-Workflow Completion |
| Дубли прошли проверку | Каждая запись вызвана отдельно | Run once with all items |
| Изменения не видны | Старая версия или другой ID | Метка v2 и версия дочернего |
Перед использованием в рабочем процессе
Проверяйте вход и выход каждой общей схемы как отдельное соглашение: имена полей, типы, статусы и ошибки. Accept all data не является валидацией. Если нужно ограничить поля интерфейса, позже можно перейти на явно заданные inputs; после этого нужно заново проверить настройки родителя.
Не добавляйте оплату, удаление, изменение цены и массовую отправку в общий дочерний workflow на этапе обучения. Правка такой схемы может повлиять сразу на нескольких вызывающих её родителей. Сначала проверьте изменение на копии, согласуйте новую версию и предусмотрите восстановление. Наши статусы — данные выполнения, не постоянный журнал и не гарантия полноты выгрузки API.
Что проверено редакцией
13 октября 2026 года сценарий проверен на n8n 2.42.4 в отдельной тестовой базе. Дочерние workflows созданы и опубликованы через локальный API n8n, родительские выполнены через CLI. Десять сценариев: исходные заказы, ноль, два корректных заказа, отрицательная сумма, null, повторяющиеся очищенные ID, USD, отсутствующий ID дочерней схемы, исключение в дочернем Code и обновление метки до v2. Точные данные, конечные ветки и отсутствие новых ready при техническом сбое подтверждены. Первоначальная публикация только командой CLI не обеспечила вызов в этой конфигурации; успешные тесты используют публикацию через API экземпляра. Интерфейс редактора, n8n Cloud, настройки межпроектных прав, режим без ожидания, отдельные вызовы для каждого item, реальные API и рабочие действия не тестировались. Учебный сервер доступен только локально; существующие workflows не менялись. Обложка — редакционная AI-иллюстрация.
Частые вопросы
Нужно ли создавать Webhook для вызова другой схемы?
Нет. В этом примере Execute Sub-workflow обращается к workflow в той же базе n8n через Execute Sub-workflow Trigger. Публичный HTTP-адрес не создаётся.
Почему файл родителя сразу не работает?
Он содержит CHILD_WORKFLOW_ID вместо ID вашей дочерней схемы. Сначала импортируйте и подготовьте дочерний workflow, затем выберите его From list в Call Order Check.
Что возвращается в родительский workflow?
В нашем примере — выход Return Result: все проверенные заказы, их status, errors и validation_version. Этот узел сохраняет остальные поля через Include Other Input Fields.
Можно ли выключить ожидание завершения?
Для этого упражнения нельзя: дальнейшая ветка зависит от проверенных статусов. Без ожидания родитель может продолжить с исходными items, а не с результатом проверки. Такой режим требует отдельной схемы получения результата.
Достаточно сохранить изменение дочерней схемы?
Это зависит от режима выполнения и версии n8n. В проверенном опубликованном вызове изменения нужно опубликовать и проверить по метке v2. Ручной редактор может использовать черновую версию; не переносите его поведение на автоматические запуски без проверки.
