Условная логика (Conditional Logic)

Условная логика — это механизм, позволяющий ПО вести себя по-разному в зависимости от значения тех или иных данных, — no-code эквивалент оператора `if/else`, выраженный визуально, а не в текстовом синтаксисе. Это один из самых фундаментальных строительных блоков во всех категориях no-code: конструкторы форм используют её для показа или скрытия вопросов (логика пропуска), платформы автоматизации используют её для разветвления workflow по разным путям (Zapier «Фильтр» или «Путь», Make «Роутер»), а приложения-базы данных используют её в полях формул для вычисления разных результатов на основе данных записи. Почему это важно: условная логика — это то, что отличает инструмент, просто перемещающий данные, от инструмента, который действительно кодирует принятие решений: именно она превращает «когда форма отправлена, отправить письмо» (простую линейную автоматизацию вообще без логики) в «когда форма отправлена, если запрошенный бюджет превышает 10 000 долларов, направить менеджеру на согласование; иначе автоматически одобрить и уведомить финансы» (workflow, отражающий реальное принятие бизнес-решений). Почти каждая нетривиальная автоматизация или приложение, создаваемое гражданским разработчиком, требует хотя бы одной условной ветви, что делает её, пожалуй, самым важным навыком no-code, который стоит освоить за пределами простого связывания триггер/действие. Как это работает: большинство платформ выражают условную логику через один из двух паттернов взаимодействия. Первый — фильтр/шлюз: единственное условие, которое либо позволяет workflow продолжиться, либо полностью его останавливает (шаг «Filter by Zapier» в Zapier — «продолжить только если стадия сделки = Закрыта успешно»). Второй — ветвление/роутер: точка принятия решения, направляющая выполнение по одному из нескольких возможных путей в зависимости от того, какое условие совпало (модуль «Роутер» в Make, условия «Прекратить этот workflow, если... / Только когда...» на каждом шаге в Bubble). Практический пример — сценарий Make, использующий Роутер для обработки трёх разных уровней качества лидов из одного триггера: Триггер: «Новая отправка формы лида». Путь роутера A (условие: `lead.company_size >= 500`): создать высокоприоритетную возможность в Salesforce и напрямую уведомить Enterprise-менеджера через Slack DM. Путь роутера B (условие: `lead.company_size >= 50 И lead.company_size < 500`): добавить в цепочку прогрева для среднего рынка в HubSpot и создать задачу с более низким приоритетом в CRM. Путь роутера C (запасной, ни одно условие не совпало — перехватывает всё остальное): добавить только в общий список рассылки, без сопровождения продажами. Эта единственная автоматизация кодирует целую политику квалификации лидов — три разных бизнес-ответа на одно и то же событие-триггер, основанных исключительно на условной оценке входящих данных — без написания разработчиком ни единого оператора `switch`.