IF и Switch в n8n: условия, ветвление и маршрутизация workflow ¶

Обновлено: 2026-05-29

IF и Switch — две основные ноды n8n для ветвления workflow. Они нужны, когда один и тот же сценарий должен идти разными путями в зависимости от данных: статуса заказа, суммы, типа события из Webhook, наличия email, роли пользователя или результата проверки.

Коротко:

• IF node подходит для выбора да / нет: условие выполнено → ветка true, не выполнено → ветка false.
• Switch node подходит для выбора из трёх и более вариантов: например new, paid, cancelled, refund, unknown.
• Обе ноды проверяют не весь workflow целиком, а каждый входящий item отдельно.
• Чаще всего ошибки возникают из-за неправильного типа данных: число приходит строкой, поле отсутствует, в значении есть пробел, отличается регистр букв или не настроен Fallback.

Эта статья поможет выбрать между IF и Switch, настроить условия, понять операторы, отладить ошибки и собрать понятные ветки в workflow.

Материал актуален для n8n 1.x и новых версий интерфейса. В старых workflow, созданных до n8n 1.0, поведение некоторых многоветочных схем с Merge может отличаться.

Быстрый выбор: IF или Switch¶

Если сомневаешься, используй простое правило: до двух вариантов — IF, три и больше — Switch.

Что важно понимать перед настройкой¶

В n8n данные между нодами передаются как массив объектов. Один объект называется item. У каждого item есть json, где лежат поля:

{
  "status": "paid",
  "amount": 4500,
  "email": "client@example.com",
  "event_type": "order_paid"
}

Когда item попадает в IF или Switch, нода проверяет значения внутри $json.

Примеры обращений к полям:

{{ $json.status }}
{{ $json.amount }}
{{ $json.email }}
{{ $json.event_type }}

Важно: IF и Switch проверяют каждый item отдельно. Если в ноду пришло 10 items, часть может уйти в одну ветку, часть — в другую.

Что такое IF node в n8n¶

IF node проверяет одно или несколько условий и разделяет поток на два выхода:

• true — условие выполнено;
• false — условие не выполнено.

IF используют, когда нужна бинарная логика: “да/нет”, “подходит/не подходит”, “есть/нет”, “больше/меньше”, “оплачено/не оплачено”.

Типовые задачи для IF:

• отправить уведомление только по новым заказам;
• пропустить лиды без email;
• разделить клиентов на VIP и обычных;
• проверить, что сумма заказа больше 5000;
• обработать только записи со статусом paid;
• отправить ошибочные данные в отдельную ветку;
• проверить, пришло ли поле из Webhook.

Пример логики:

Webhook → IF
           true  → Telegram: отправить уведомление
           false → ничего не делать или записать в лог

Как настроить IF node пошагово¶

Представим, что в workflow приходит заказ:

{
  "order_id": 1001,
  "status": "paid",
  "amount": 3400,
  "email": "buyer@example.com"
}

Нужно отправлять уведомление только по оплаченным заказам.

Шаги настройки¶

1. Открой workflow в n8n.
2. Добавь ноду IF.
3. В первом поле условия выбери значение через Expression:

{{ $json.status }}

1. Выбери тип данных String.
2. Выбери операцию is equal to / Equal.
3. Во втором поле укажи:

paid

1. Выполни ноду через Execute step.
2. Проверь, в какой выход попал item.
3. Подключи выход true к Telegram, Email, HTTP Request или другой ноде.
4. Подключи выход false к логированию, No Operation или оставь пустым, если такие items не нужны.

Итоговая схема:

Webhook → IF status = paid
           true  → Telegram: "Заказ оплачен"
           false → Set: error = "not_paid"

Как использовать ветки true и false¶

У IF всегда два выхода. Они появляются справа от ноды.

Если ветка не подключена, items из неё не пойдут дальше. Это нормально, если ты специально фильтруешь данные. Но если нужно сохранить все записи, подключай обе ветки.

Примеры:

True  → отправить уведомление
False → ничего не делать

True  → записать лид в CRM
False → записать ошибку "нет email"

True  → обработка VIP-клиента
False → стандартная обработка

Несколько условий в IF: AND и OR¶

В IF можно добавить несколько условий. Между ними выбирается логика:

• AND — item проходит, только если выполнены все условия.
• OR — item проходит, если выполнено хотя бы одно условие.

Пример AND¶

Нужно отправить уведомление, если заказ оплачен и сумма больше 1000.

Condition 1:
{{ $json.status }} Equal paid

Condition 2:
{{ $json.amount }} Greater Than 1000

Mode:
AND

Логика:

status === 'paid' && amount > 1000

Пример OR¶

Нужно обработать заказ, если статус new или pending.

Condition 1:
{{ $json.status }} Equal new

Condition 2:
{{ $json.status }} Equal pending

Mode:
OR

Логика:

status === 'new' || status === 'pending'

Когда лучше не усложнять IF¶

Если условий становится слишком много, workflow быстро теряет читаемость. Например:

status = new
status = paid
status = cancelled
status = refund
status = failed

Такую логику лучше перенести в Switch, потому что каждый вариант станет отдельным выходом.

Операторы IF node¶

Оператор определяет, как IF сравнивает значения. В n8n набор операторов зависит от типа данных: String, Number, Date & Time, Boolean, Array, Object.

Основные операторы¶

Примеры условий¶

Empty, null, undefined и пустая строка: в чём разница¶

Многие ошибки в IF возникают из-за того, что “пустое значение” бывает разным.

Надёжная проверка email:

{{ !!$json.email && $json.email.trim() !== '' }}

Проверка, что поле отсутствует или пустое:

{{ !$json.email || $json.email.trim() === '' }}

Проверка null или undefined:

{{ $json.field == null }}

Здесь специально используется ==, а не ===, потому что выражение поймает и null, и undefined.

Что такое Switch node в n8n¶

Switch node направляет item в один из нескольких выходов по значению поля или результату выражения. По смыслу это похоже на switch/case в JavaScript.

Switch используют, когда вариантов больше двух.

Пример:

{
  "event_type": "order_paid"
}

Маршрутизация:

event_type = lead_created → выход 0 → CRM
event_type = order_paid   → выход 1 → Telegram
event_type = call_missed  → выход 2 → задача менеджеру
другое значение           → fallback → лог ошибок

Switch особенно полезен для:

• статусов заказа;
• типов событий из Webhook;
• категорий клиентов;
• разных источников лидов;
• разных каналов уведомлений;
• маршрутизации заявок по отделам;
• обработки нескольких сценариев в одном workflow.

Как настроить Switch node пошагово¶

Допустим, из Webhook приходит событие:

{
  "event_type": "payment_succeeded",
  "order_id": 1001,
  "amount": 4500
}

Нужно направить разные события в разные ветки.

Шаги настройки¶

1. Добавь ноду Switch после Webhook.
2. В параметре Mode выбери Rules.
3. Добавь первое правило.
4. В Value 1 укажи:

{{ $json.event_type }}

1. Выбери оператор Equal.
2. Укажи значение:

lead_created

1. Добавь второе правило:

{{ $json.event_type }} Equal payment_succeeded

1. Добавь третье правило:

{{ $json.event_type }} Equal payment_failed

1. Включи Fallback Output, чтобы неизвестные события не терялись.
2. Подключи каждый выход к своей ноде.

Схема:

Webhook → Switch event_type
           0 lead_created       → CRM
           1 payment_succeeded  → Telegram
           2 payment_failed     → Email
           3 fallback           → Google Sheets: лог неизвестных событий

Режимы Switch: Rules и Expression¶

У Switch есть два основных режима.

Режим Rules¶

В режиме Rules ты создаёшь правила в интерфейсе. Каждое правило сравнивает значение и отправляет item в нужный выход.

Пример правил:

Rule 1:
{{ $json.status }} Equal new
→ Output 0

Rule 2:
{{ $json.status }} Equal paid
→ Output 1

Rule 3:
{{ $json.status }} Equal cancelled
→ Output 2

Fallback:
любое другое значение
→ Output 3

Этот режим лучше использовать в 90% случаев, потому что он читается проще и понятнее для команды.

Режим Expression¶

В режиме Expression нода ждёт выражение, которое вернёт номер выхода.

Пример: разделить заказы по сумме.

{{ $json.amount >= 5000 ? 0 : $json.amount >= 1000 ? 1 : 2 }}

Расшифровка:

Такой режим полезен, если логика компактная. Но если выражение становится длинным, лучше вынести подготовку данных в Code node, а в Switch оставить простые правила.

Важные настройки Switch node¶

У Switch есть параметры, которые часто решают проблему “почему данные не туда ушли”.

Fallback Output¶

Fallback Output определяет, что делать с item, который не совпал ни с одним правилом.

Рекомендация: в рабочих workflow почти всегда включай Extra Output. Так ты не потеряешь неожиданные статусы и сможешь записать их в лог.

Ignore Case¶

Если включить Ignore Case, Switch не будет различать регистр букв.

Например, эти значения будут считаться одинаковыми:

paid
PAID
Paid

Это полезно, если данные приходят из внешних API, форм или таблиц, где регистр может отличаться.

Less Strict Type Validation¶

Эта настройка позволяет n8n мягче сравнивать значения разных типов.

Например:

{
  "amount": "1000"
}

Формально "1000" — строка, а не число. При строгой проверке сравнение с числом может дать неожиданный результат. Лучше не полагаться только на мягкую валидацию, а явно приводить тип:

{{ Number($json.amount) }}

Send data to all matching outputs¶

По умолчанию Switch часто используют как выбор одного пути. Но в некоторых сценариях item должен уйти во все подходящие ветки.

Например, клиент:

{
  "amount": 7000,
  "is_vip": true
}

Он может одновременно подходить под условия:

• крупный заказ;
• VIP-клиент;
• требуется уведомление менеджера.

Если включить Send data to all matching outputs, item может попасть в несколько выходов сразу. Используй это осторожно: такая логика может создать дублирующиеся действия, например несколько уведомлений или несколько записей в CRM.

Rename Output¶

Rename Output помогает дать выходам понятные имена вместо Output 0, Output 1, Output 2.

Например:

Output 0 → new_order
Output 1 → paid_order
Output 2 → cancelled_order
Output 3 → unknown_status

Это улучшает читаемость больших workflow.

IF vs Switch: подробное сравнение¶

Примеры IF в workflow¶

Пример 1. Уведомлять менеджера только при новом заказе¶

Входные данные:

{
  "status": "new",
  "order_id": 1001,
  "amount": 2400
}

Настройка IF:

Value 1: {{ $json.status }}
Operation: Equal
Value 2: new

Схема:

Webhook → IF status = new
           true  → Telegram: "Новый заказ #1001"
           false → No Operation

Когда использовать: если нужно реагировать только на новые события, а остальные пропускать.

Пример 2. Не отправлять лид в CRM без email¶

Входные данные:

{
  "name": "Иван",
  "email": "",
  "phone": "+79990000000"
}

Настройка IF:

Value 1: {{ $json.email }}
Operation: Not Empty

Схема:

Webhook → IF email Not Empty
           true  → HTTP Request: создать лид в CRM
           false → Google Sheets: записать ошибку no_email

Улучшенная проверка через выражение:

{{ !!$json.email && $json.email.trim() !== '' }}

Так ты отсекаешь не только пустую строку, но и строку из пробелов.

Пример 3. Разделить заказы по сумме¶

Входные данные:

{
  "order_id": 1002,
  "amount": "7500"
}

Если сумма приходит строкой, сначала приведи её к числу:

{{ Number($json.amount) }}

Настройка IF:

Value 1: {{ Number($json.amount) }}
Operation: Greater Than
Value 2: 5000

Схема:

Webhook → IF amount > 5000
           true  → Telegram: крупный заказ
           false → стандартная обработка

Пример 4. Проверить дату события¶

Входные данные:

{
  "created_at": "2026-05-26T10:30:00.000Z"
}

Настройка IF:

Value 1: {{ $json.created_at }}
Type: Date & Time
Operation: After
Value 2: 2026-05-01

Так можно обрабатывать только новые записи, события за текущий месяц или заявки после определённой даты.

Примеры Switch в workflow¶

Пример 1. Обработка статусов заказа¶

Входные данные:

{
  "status": "paid",
  "order_id": 1001
}

Настройка Switch:

Mode: Rules

Rule 1:
{{ $json.status }} Equal new
→ Output 0: new_order

Rule 2:
{{ $json.status }} Equal paid
→ Output 1: paid_order

Rule 3:
{{ $json.status }} Equal cancelled
→ Output 2: cancelled_order

Fallback:
→ Output 3: unknown_status

Схема:

Webhook → Switch status
           new       → Telegram: новый заказ
           paid      → CRM: обновить оплату
           cancelled → Email: уведомить клиента
           fallback  → Google Sheets: неизвестный статус

Пример 2. Маршрутизация событий из Webhook¶

Входные данные:

{
  "event_type": "lead_created",
  "lead_id": 123,
  "source": "site"
}

Настройка Switch:

{{ $json.event_type }} Equal lead_created       → CRM
{{ $json.event_type }} Equal payment_succeeded  → Telegram
{{ $json.event_type }} Equal call_missed        → задача менеджеру
{{ $json.event_type }} Equal form_spam          → лог спама
Fallback                                      → лог неизвестных событий

Схема:

Webhook → Switch event_type
           lead_created      → CRM
           payment_succeeded → Telegram
           call_missed       → Notion / задача
           form_spam         → Google Sheets spam log
           fallback          → Google Sheets unknown events

Почему Fallback важен: внешний сервис может добавить новый тип события, переименовать статус или прислать ошибочное значение. Без Fallback такие items легко потерять.

Пример 3. Сегментация клиентов по сумме заказа¶

Входные данные:

{
  "client_id": 77,
  "amount": 8500
}

Вариант через Rules:

{{ Number($json.amount) }} Greater Than 10000 → VIP
{{ Number($json.amount) }} Greater Than 5000  → high_value
{{ Number($json.amount) }} Greater Than 1000  → regular
Fallback                                     → low_value

Важный момент: порядок правил имеет значение, если item отправляется только в первый совпавший выход. Более конкретные условия ставь выше.

Правильно:

amount > 10000
amount > 5000
amount > 1000

Неправильно:

amount > 1000
amount > 5000
amount > 10000

Если первым стоит amount > 1000, заказ на 12000 может уйти в обычную ветку раньше, чем дойдёт до VIP-условия.

Как объединить ветки обратно через Merge¶

После IF или Switch ветки можно снова объединить через Merge node, если дальнейшая обработка одинаковая.

Пример:

Webhook → IF email заполнен?
           true  → Set status = valid   ↘
                                     Merge → HTTP Request → Telegram
           false → Set status = invalid ↗

Когда это полезно:

• нужно добавить разные поля в разных ветках, а потом отправить общий отчёт;
• нужно нормализовать данные перед одной финальной нодой;
• нужно сохранить все items, но пометить их разными статусами.

Когда лучше не объединять:

• если ветки делают принципиально разные действия;
• если одна ветка должна завершиться;
• если после объединения появляются дубли;
• если workflow старый и использует legacy execution order.

Для workflow, созданных до n8n 1.0, проверь настройки выполнения. В старом режиме связка IF + Merge могла вести себя иначе: Merge мог запускать обе ветки даже при фактическом прохождении item только по одной ветке. В новых workflow это поведение убрано, но старые сценарии лучше проверить отдельно.

Как отлаживать IF и Switch¶

Если условие не работает, не начинай с переписывания workflow. Сначала проверь входные данные.

Чек-лист отладки¶

1. Выполни предыдущую ноду.
2. Открой IF или Switch.
3. Перейди во вкладку Input.
4. Найди нужное поле.
5. Скопируй точный путь к полю.
6. Проверь тип данных: строка, число, boolean, массив, объект.
7. Проверь пробелы в начале и конце строки.
8. Проверь регистр букв.
9. Проверь, не лежит ли поле глубже: например $json.data.status.
10. Выполни IF/Switch через Execute step.
11. Посмотри, сколько items попало в каждый выход.
12. Для Switch проверь Fallback.

Быстрая диагностика через Code node¶

Поставь Code node перед IF или Switch:

return $input.all().map(item => ({
  json: {
    ...item.json,
    debug_amount_type: typeof item.json.amount,
    debug_amount_value: item.json.amount,
    debug_status_type: typeof item.json.status,
    debug_status_value: item.json.status,
    debug_status_trimmed: typeof item.json.status === 'string'
      ? item.json.status.trim()
      : item.json.status
  }
}));

После этого ты увидишь, что реально приходит в ноду: число или строка, paid или paid, поле есть или отсутствует.

Частые ошибки IF и Switch в n8n¶

Практические выражения для IF и Switch¶

Привести строку к числу¶

{{ Number($json.amount) }}

Убрать пробелы по краям¶

{{ $json.status.trim() }}

Сравнить строку без учёта регистра¶

{{ $json.status.toLowerCase() }}

И сравнивать уже с:

paid

Проверить, что email заполнен¶

{{ !!$json.email && $json.email.trim() !== '' }}

Проверить, что массив не пустой¶

{{ Array.isArray($json.items) && $json.items.length > 0 }}

Проверить вложенное поле без ошибки¶

{{ $json.customer?.email }}

Вернуть выход Switch по сумме¶

{{ Number($json.amount) >= 10000 ? 0 : Number($json.amount) >= 5000 ? 1 : 2 }}

Нормализовать статус перед Switch¶

{{ String($json.status || '').trim().toLowerCase() }}

Лучшие практики¶

1. Называй выходы Switch понятными словами¶

Плохо:

Output 0
Output 1
Output 2

Лучше:

new_order
paid_order
cancelled_order
unknown_status

2. Добавляй Fallback почти всегда¶

Если внешний сервис прислал неожиданный статус, лучше записать его в лог, чем потерять item.

Fallback → Google Sheets / Data Table / лог ошибок

3. Нормализуй данные до условий¶

Перед IF/Switch полезно поставить Set/Edit Fields или Code node:

return $input.all().map(item => ({
  json: {
    ...item.json,
    status_normalized: String(item.json.status || '').trim().toLowerCase(),
    amount_number: Number(item.json.amount || 0)
  }
}));

После этого условия будут проще:

status_normalized Equal paid
amount_number Greater Than 5000

4. Не строй длинные цепочки IF¶

Если в workflow появляется такая схема:

IF → IF → IF → IF → IF

скорее всего, нужен Switch.

5. Логируй неизвестные значения¶

Для продакшен-workflow полезно сохранять неожиданные статусы:

{
  "error": "unknown_status",
  "status": "{{ $json.status }}",
  "payload": "{{ JSON.stringify($json) }}"
}

6. Проверяй типы данных после Webhook и Google Sheets¶

Webhook, формы и Google Sheets часто отдают числа как строки. Поэтому 1000 и "1000" — не одно и то же.

Готовая схема workflow для проверки IF¶

Минимальный тестовый сценарий:

Manual Trigger
→ Code: сгенерировать тестовые заказы
→ IF: status = paid AND amount > 1000
→ true: Set result = "send_notification"
→ false: Set result = "skip"

Код для тестовых данных:

return [
  {
    json: {
      order_id: 1,
      status: 'paid',
      amount: 2500,
      email: 'client1@example.com'
    }
  },
  {
    json: {
      order_id: 2,
      status: 'new',
      amount: 800,
      email: 'client2@example.com'
    }
  },
  {
    json: {
      order_id: 3,
      status: 'paid',
      amount: 500,
      email: ''
    }
  }
];

Условие IF:

Condition 1:
{{ $json.status }} Equal paid

Condition 2:
{{ Number($json.amount) }} Greater Than 1000

Mode:
AND

Ожидаемый результат:

Готовая схема workflow для проверки Switch¶

Минимальный тестовый сценарий:

Manual Trigger
→ Code: сгенерировать события
→ Switch: event_type
→ lead_created       → Set handler = crm
→ payment_succeeded  → Set handler = telegram
→ call_missed        → Set handler = task
→ fallback           → Set handler = unknown_event

Код для тестовых событий:

return [
  {
    json: {
      event_type: 'lead_created',
      lead_id: 101
    }
  },
  {
    json: {
      event_type: 'payment_succeeded',
      order_id: 202
    }
  },
  {
    json: {
      event_type: 'call_missed',
      phone: '+79990000000'
    }
  },
  {
    json: {
      event_type: 'new_external_event',
      raw_payload: true
    }
  }
];

Правила Switch:

{{ $json.event_type }} Equal lead_created      → Output 0
{{ $json.event_type }} Equal payment_succeeded → Output 1
{{ $json.event_type }} Equal call_missed       → Output 2
Fallback Output: Extra Output                  → Output 3

Ожидаемый результат:

IF и Switch в связке с другими нодами¶

Полезные связанные материалы:

• n8n Webhook — как принимать входящие события.
• n8n Code node — как писать JavaScript и Python в workflow.
• n8n Merge node — как объединять ветки.
• Выражения в n8n — как обращаться к полям через $json.
• Работа с данными в n8n — как устроены items и JSON.
• Логика workflow — общие принципы ветвления и обработки ошибок.

Чек-лист перед публикацией workflow¶

Перед тем как включить workflow в продакшене, проверь:

• У IF подключены нужные ветки true и false.
• У Switch включён Fallback для неизвестных значений.
• Все числовые поля действительно числа, а не строки.
• Строки очищаются от пробелов через .trim(), если данные приходят от пользователей.
• Регистр нормализован или включён Ignore Case.
• Вложенные поля указаны правильным путём.
• После Merge нет дублей.
• Ошибочные items логируются.
• На тестовых данных каждая ветка реально выполнялась хотя бы один раз.
• В workflow есть понятные названия нод и выходов.

Часто задаваемые вопросы¶

Чем IF отличается от Switch в n8n?¶

IF делит данные на два выхода: true и false. Switch нужен для нескольких выходов: например new, paid, cancelled, unknown. Если вариантов два — используй IF. Если вариантов три и больше — Switch.

Можно ли использовать IF без ветки false?¶

Да. Если ветка false не подключена, items из неё просто не пойдут дальше. Это нормально для фильтрации, но опасно, если тебе нужно сохранить все данные.

Что произойдёт, если Switch не найдёт совпадение?¶

Зависит от настройки Fallback Output. Если стоит None, item будет проигнорирован. Если выбран Extra Output, item уйдёт в отдельную fallback-ветку. Если выбран Output 0, item попадёт в первый выход.

Почему IF не срабатывает на число?¶

Частая причина — число пришло как строка. Например, "5000" выглядит как число, но технически это string. Используй приведение типа:

{{ Number($json.amount) }}

Как проверить, что поле существует?¶

Используй оператор Exists. Если нужно проверить, что поля нет, используй Does not exist.

Как проверить пустой email?¶

Самый простой вариант — оператор Not Empty. Более надёжный вариант для пользовательских данных:

{{ !!$json.email && $json.email.trim() !== '' }}

Как проверить null или undefined?¶

Используй выражение:

{{ $json.field == null }}

Оно сработает и для null, и для undefined.

Можно ли использовать регулярные выражения в IF и Switch?¶

Да. Для строк можно использовать оператор Regex / Matches Regex. Например, чтобы проверить статус, который начинается с paid:

^paid

Можно ли отправить item сразу в несколько выходов Switch?¶

Да, если включить настройку Send data to all matching outputs. Используй её осторожно, потому что один item может запустить несколько действий.

Что лучше: один Switch или несколько IF подряд?¶

Если вариантов больше двух, лучше Switch. Он проще читается, легче отлаживается и лучше масштабируется.

Как объединить ветки IF обратно?¶

Используй Merge node. Но проверь режим Merge и поведение старых workflow, особенно если сценарий был создан до n8n 1.0.

Нужно ли логировать ветку false?¶

Для учебных workflow — не всегда. Для продакшена — желательно. Ветка false часто показывает не ошибку, а важный альтернативный сценарий: нет email, неизвестный статус, невалидная заявка, неподдерживаемое событие.

Кратко¶

IF и Switch — базовые ноды для логики workflow в n8n.

• IF нужен для двух вариантов: true и false.
• Switch нужен для трёх и более вариантов.
• IF удобен для проверок: поле заполнено, сумма больше X, статус равен Y.
• Switch удобен для маршрутизации: статус заказа, тип события, категория клиента.
• Для Switch почти всегда стоит включать Fallback Output.
• Для чисел из Webhook, Google Sheets и форм лучше использовать Number().
• Для строк из пользовательских источников полезны .trim() и .toLowerCase().
• Если условие не работает, сначала проверь входной JSON, тип данных и точный путь к полю.
• Если workflow старый и использует Merge после IF, проверь настройки execution order.

Источники и документация¶

• Официальная документация n8n: IF node
• Официальная документация n8n: Switch node
• Официальная документация n8n: ветвление с условиями
• Официальная документация n8n: Merge node

Практика использования ноды

Страница IF и Switch в n8n: условия, ветвление и маршрутизация workflow должна отвечать за поведение ноды, а не за полный бизнес-рецепт. Поэтому при внедрении фиксируйте вход, выход и изменение количества items.