[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-conditional-logic::ru":3,"gloss-cluster-conditional-logic::ru":23,"gloss-next-conditional-logic::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"conditional-logic","no-code","Условная логика (Conditional Logic)","Условная логика — это механизм, позволяющий ПО вести себя по-разному в зависимости от значения тех или иных данных, — no-code эквивалент оператора `if\u002Felse`, выраженный визуально, а не в текстовом синтаксисе. Это один из самых фундаментальных строительных блоков во всех категориях no-code: конструкторы форм используют её для показа или скрытия вопросов (логика пропуска), платформы автоматизации используют её для разветвления workflow по разным путям (Zapier «Фильтр» или «Путь», Make «Роутер»), а приложения-базы данных используют её в полях формул для вычисления разных результатов на основе данных записи. Почему это важно: условная логика — это то, что отличает инструмент, просто перемещающий данные, от инструмента, который действительно кодирует принятие решений: именно она превращает «когда форма отправлена, отправить письмо» (простую линейную автоматизацию вообще без логики) в «когда форма отправлена, если запрошенный бюджет превышает 10 000 долларов, направить менеджеру на согласование; иначе автоматически одобрить и уведомить финансы» (workflow, отражающий реальное принятие бизнес-решений). Почти каждая нетривиальная автоматизация или приложение, создаваемое гражданским разработчиком, требует хотя бы одной условной ветви, что делает её, пожалуй, самым важным навыком no-code, который стоит освоить за пределами простого связывания триггер\u002Fдействие. Как это работает: большинство платформ выражают условную логику через один из двух паттернов взаимодействия. Первый — фильтр\u002Fшлюз: единственное условие, которое либо позволяет workflow продолжиться, либо полностью его останавливает (шаг «Filter by Zapier» в Zapier — «продолжить только если стадия сделки = Закрыта успешно»). Второй — ветвление\u002Fроутер: точка принятия решения, направляющая выполнение по одному из нескольких возможных путей в зависимости от того, какое условие совпало (модуль «Роутер» в Make, условия «Прекратить этот workflow, если... \u002F Только когда...» на каждом шаге в Bubble). Практический пример — сценарий Make, использующий Роутер для обработки трёх разных уровней качества лидов из одного триггера: Триггер: «Новая отправка формы лида». Путь роутера A (условие: `lead.company_size >= 500`): создать высокоприоритетную возможность в Salesforce и напрямую уведомить Enterprise-менеджера через Slack DM. Путь роутера B (условие: `lead.company_size >= 50 И lead.company_size \u003C 500`): добавить в цепочку прогрева для среднего рынка в HubSpot и создать задачу с более низким приоритетом в CRM. Путь роутера C (запасной, ни одно условие не совпало — перехватывает всё остальное): добавить только в общий список рассылки, без сопровождения продажами. Эта единственная автоматизация кодирует целую политику квалификации лидов — три разных бизнес-ответа на одно и то же событие-триггер, основанных исключительно на условной оценке входящих данных — без написания разработчиком ни единого оператора `switch`.","Условная логика позволяет workflow, форме или приложению вести себя по-разному в зависимости от данных — ветвление «если это, то то» без написания кода.",null,[11,14,17,20],{"slug":12,"name":13},"action","Действие (Action)",{"slug":15,"name":16},"business-logic","Бизнес-логика (Business Logic)",{"slug":18,"name":19},"trigger","Триггер (Trigger)",{"slug":21,"name":22},"workflow-automation","Автоматизация рабочих процессов (Workflow Automation)",[24,26,30,33,36,39,42,45,48,51,54,57],{"slug":12,"category":5,"name":13,"updated_at":25},"2026-08-24T02:46:36+00:00",{"slug":27,"category":5,"name":28,"updated_at":29},"aggregator","Агрегатор (Aggregator)","2026-08-24T02:46:37+00:00",{"slug":31,"category":5,"name":32,"updated_at":25},"airtable","Airtable",{"slug":34,"category":5,"name":35,"updated_at":25},"api","API",{"slug":37,"category":5,"name":38,"updated_at":25},"api-key","API-ключ (API Key)",{"slug":40,"category":5,"name":41,"updated_at":29},"approval-workflow","Процесс согласования (Approval Workflow)",{"slug":43,"category":5,"name":44,"updated_at":25},"automation-platform","Платформа автоматизации (Automation Platform)",{"slug":46,"category":5,"name":47,"updated_at":25},"automation-recipe","Рецепт автоматизации (Automation Recipe)",{"slug":49,"category":5,"name":50,"updated_at":25},"backend-as-a-service","Backend как услуга (BaaS)",{"slug":52,"category":5,"name":53,"updated_at":29},"backfill","Обратное заполнение (Backfill)",{"slug":55,"category":5,"name":56,"updated_at":25},"bubble","Bubble",{"slug":15,"category":5,"name":16,"updated_at":25}]