Бизнес-процессы в Битрикс24: как создать, настроить и запустить
12.08.2026
Коротко: бизнес-процесс в Битрикс24 — это заданная схема прохождения работы через людей: кто и в каком порядке согласует, что происходит при отказе, куда уходит документ дальше. От роботов он отличается тем, что умеет ветвиться, ждать решения человека и возвращаться на предыдущий шаг. Собирается в визуальном дизайнере без программирования, но осмысленно работает только там, где процесс сначала описан на бумаге. Ниже — как устроены шаблоны, запуск и отладка.
Содержание:
- Что такое бизнес-процесс и чем он отличается от робота
- Где в Битрикс24 работают бизнес-процессы
- Дизайнер бизнес-процессов: из чего собирается схема
- Как создать бизнес-процесс: пример согласования счёта
- Параметры, переменные и права
- Запуск: вручную, автоматически, по событию
- Отладка и типичные сбои
- Когда бизнес-процесс не нужен
- Частые вопросы
Что такое бизнес-процесс и чем он отличается от робота
Бизнес-процесс — это описанная последовательность шагов, которую система проводит сама: ставит задания людям, ждёт их решения, выбирает ветку в зависимости от ответа, меняет данные, уведомляет участников. Пока процесс идёт, у него есть состояние: видно, на ком он сейчас и сколько там висит.
Робот проще: это одно действие, привязанное к стадии. Сделка перешла на стадию — робот отправил письмо или поставил задачу. Робот не умеет ждать ответа и разветвлять сценарий по этому ответу.
Отсюда практическое разделение. Линейная автоматизация внутри CRM — роботы: они настраиваются быстрее, понятнее менеджерам и реже ломаются. Согласования, ветвления, возвраты на доработку, многошаговые маршруты между отделами — бизнес-процессы.
| Критерий | Робот | Бизнес-процесс |
|---|---|---|
| Что делает | Одно действие на стадии | Многошаговый маршрут |
| Ветвления | Нет | Есть, по условиям и ответам |
| Ожидание решения человека | Нет | Да, задания с ответами |
| Возврат на предыдущий шаг | Нет | Да |
| Сложность настройки | Низкая | Средняя и выше |
| Типовые задачи | Письмо, задача, смена ответственного | Согласование, заявки, маршруты документов |
Где в Битрикс24 работают бизнес-процессы
Первое место — CRM: процессы запускаются на лидах, сделках, контактах и компаниях. Типичный сценарий — согласование скидки или нестандартных условий договора перед отправкой клиенту.
Второе — универсальные списки. Это простые справочники, которые заводятся под что угодно: заявки на закупку, реестр договоров, учёт оборудования. Процесс на списке превращает его в полноценную заявочную систему с маршрутом согласования.
Третье — документы и Диск: согласование файла по цепочке ответственных с фиксацией решений.
Четвёртое — процессы в живой ленте: заявления на отпуск, командировки, служебные записки. Здесь Битрикс24 даёт готовые шаблоны, которые достаточно поправить под свою структуру.
Важный нюанс: бизнес-процессы доступны не на всех тарифах, и набор инструментов различается. Прежде чем проектировать сложную схему, стоит убедиться, что она поддерживается вашим планом — сравнить тарифы можно на сайте сервиса. В коробочной версии ограничений меньше, но там свои требования к серверу, о чём написано в статье Битрикс24 Коробка.
Дизайнер бизнес-процессов: из чего собирается схема
Шаблон процесса собирается в визуальном дизайнере: блоки перетаскиваются на схему и соединяются в цепочку. Программировать не требуется, но логику продумать придётся.
Основные группы блоков такие. Действия с документом меняют данные элемента: записывают поле, меняют стадию, ставят статус. Задания сотрудникам — блоки, которые ждут человека: согласование с ответами «да» и «нет», ознакомление, ввод данных в поля. Уведомления отправляют письмо или сообщение в портал. Конструкции управляют потоком: условие с ветками, параллельное выполнение, пауза, цикл.
Отдельно стоит блок постановки задачи: процесс создаёт задачу исполнителю и, если нужно, ждёт её завершения, прежде чем идти дальше. Это самая частая связка процессов с обычной работой команды — как устроены задачи и роли в них, разобрано в статье задачи в Битрикс24.
Полезный приём проектирования: сначала нарисовать схему на бумаге в виде вопросов и ответов, и только потом собирать её в дизайнере. Схема, придуманная прямо в интерфейсе, почти всегда получается запутанной и потом переделывается.
Основные блоки дизайнера и что они делают
Названия блоков в дизайнере зависят от версии и места запуска (CRM, списки, Диск), но основной набор везде похож. Ниже — блоки, из которых собирается большинство рабочих схем.
| Блок | Что делает | Когда нужен |
|---|---|---|
| Утверждение документа | Ставит сотрудникам задание с ответами «утвердить / отклонить» и ждёт решения | Согласование счёта, скидки, договора |
| Ознакомление с документом | Просит отметить, что сотрудник прочитал документ | Приказы, регламенты, изменения условий |
| Запрос дополнительной информации | Задание, в котором сотрудник заполняет поля, а процесс забирает ответы | Бухгалтерия вносит дату оплаты, юрист — номер договора |
| Задача | Создаёт обычную задачу и может ждать её завершения | Работа с результатом: подготовить документы, отгрузить |
| Условие | Делит схему на ветки по значению поля, переменной или ответа | Порог суммы, тип клиента, результат согласования |
| Параллельное выполнение | Запускает несколько веток одновременно | Юрист и бухгалтер согласуют независимо друг от друга |
| Пауза в выполнении | Останавливает процесс на заданный срок или до даты | Напомнить через три дня, подождать дату оплаты |
| Цикл | Повторяет шаги, пока выполняется условие | Возврат заявки на доработку до утверждения |
| Изменение документа, установка переменной | Записывают значения в поля элемента или внутреннюю память процесса | Статус заявки, сумма, имя согласующего |
| Уведомление, почтовое сообщение | Сообщают участникам о событии | Инициатору — об отказе, бухгалтерии — о новой заявке |
Задания отличаются от уведомлений главным: процесс на них останавливается и ждёт человека. Уведомление ушло — схема сразу идёт дальше. Поэтому всё, что требует решения, собирается на блоках-заданиях, а не на сообщениях с просьбой «ответить в чате».
Ожидание и параллельные ветки
Частый вопрос — как сделать, чтобы следующий шаг запускался только после того, как сотрудник выполнил задачу. В бизнес-процессе это решает блок задачи с ожиданием завершения: процесс ставит задачу и стоит на этом шаге, пока её не закроют, а потом идёт дальше. Если задачу нужно не просто закрыть, а проверить, после неё ставят блок утверждения постановщику. У роботов CRM такой цепочки «задача — ждать — следующая задача» нет: робот ставит задачу и на этом его работа заканчивается, поэтому многошаговые поручения удобнее собирать процессом, который запускается роботом на нужной стадии.
Ожидание по времени — отдельная вещь. В бизнес-процессе это пауза на срок или до даты, у роботов — отложенный запуск или отдельное условие ожидания. Путать их не стоит: пауза ждёт календаря, а задание или задача — человека.
Параллельное выполнение нужно, когда согласующие не зависят друг от друга. Вместо цепочки «юрист, потом бухгалтер» обе ветки стартуют сразу, и процесс идёт дальше, когда закончены все. Это сокращает срок согласования вдвое, но требует продумать отказ: если одна ветка отклонила заявку, вторая обычно уже не нужна, и это правило надо прописать условием после параллельного блока.
Шаблоны бизнес-процессов: готовые и свои
Любой бизнес-процесс существует в двух видах: шаблон — это схема в дизайнере, а экземпляр — конкретный запуск этой схемы на конкретной сделке или заявке. Правка шаблона влияет на новые запуски; уже идущие процессы продолжают работать по той версии схемы, с которой стартовали.
Готовые шаблоны Битрикс24 есть для типовых процессов в живой ленте: отпуск, командировка, служебная записка, счёт на оплату. Их разумно брать за основу и править под свою структуру, а не собирать с нуля. Для CRM и универсальных списков шаблоны создаются под задачу, отдельно для каждого типа элемента: процесс для сделок не запустится на лиде.
Шаблон можно выгрузить в файл и загрузить в другой список или на другой портал. Это удобно, чтобы собрать и отладить схему на тестовом списке, а потом перенести в рабочий. После импорта нужно проверить поля и участников: коды полей и сотрудники на другом портале отличаются, и блоки, которые на них ссылаются, придётся переназначить.
Опишем процесс, соберём шаблон, настроим права и запуск, проверим на реальных заявках. Подробнее — внедрение и настройка Битрикс24.
Как создать бизнес-процесс: пример согласования счёта
Разберём типовую схему, которая нужна почти любой компании: сотрудник просит оплатить счёт, счёт согласуют руководитель и бухгалтерия.
Шаг 1. Место хранения. Заводим универсальный список «Заявки на оплату» с полями: сумма, контрагент, назначение платежа, файл счёта, желаемая дата оплаты, инициатор.
Шаг 2. Условие по сумме. Первым блоком ставим ветвление: если сумма меньше порога, заявка идёт сразу в бухгалтерию, если больше — сначала к руководителю. Это снимает с директора поток мелких согласований.
Шаг 3. Согласование. Блок задания руководителю с двумя ответами. При отказе процесс уходит в ветку возврата: инициатор получает уведомление с комментарием и может исправить заявку.
Шаг 4. Бухгалтерия. Второе задание: проверить реквизиты и подтвердить оплату. Здесь же процесс записывает в список дату оплаты.
Шаг 5. Завершение. Статус заявки меняется на оплаченную, инициатор получает уведомление. Процесс закончен, а в списке остаётся история: кто просил, кто согласовал, когда оплатили.
Такая схема собирается за несколько часов и почти сразу окупается: исчезают потерянные счета и разговоры «я тебе отправлял на согласование».
Согласование: один, все или голосованием
Блок утверждения умеет работать с несколькими согласующими, и от выбранного режима зависит, когда процесс пойдёт дальше. Первый режим — достаточно решения любого из участников: удобно, когда согласовать может любой из заместителей. Второй — нужны решения всех: каждый из списка должен утвердить, а отказ одного останавливает заявку. Третий — голосование: процесс считает долю «за» и сравнивает с заданным процентом.
На практике для денег и договоров выбирают «все» или последовательную цепочку, для внутренних заявок — «любой». Голосование встречается редко: оно подходит для коллегиальных решений, но в обычных согласованиях только размывает ответственность. Отдельно стоит задать срок задания и что делать при его истечении — иначе процесс будет ждать согласующего бесконечно.
Параметры, переменные и права
Параметры — это то, что процесс спрашивает у пользователя при запуске: например, комментарий или выбор согласующего. Они удобны, когда часть данных нельзя взять из карточки.
Переменные — внутренняя память процесса. В них складывают промежуточные значения: результат согласования, посчитанную сумму, имя согласующего. Без переменных сложные схемы приходится строить обходными путями.
Константы хранят настройки, которые меняются редко: порог суммы, адрес почты бухгалтерии. Вынести их в константы стоит обязательно — иначе при смене порога придётся править схему в нескольких местах.
Отдельно настраиваются права на сам шаблон: кто может его запускать, кто редактировать, кто видеть ход выполнения. Право на редактирование шаблона должно быть у одного-двух человек: процесс, который правят все, ломается быстро и незаметно. Как устроены роли и уровни доступа в портале, разобрано в статье права доступа в Битрикс24.
Запуск: вручную, автоматически, по событию
Процесс может стартовать тремя способами. Вручную — сотрудник открывает элемент и нажимает запуск. Так работают заявления, служебные записки, разовые согласования.
При создании элемента — процесс запускается автоматически, как только появился новый элемент списка или новая сделка. Подходит для заявок, которые всегда идут по одному маршруту.
При изменении элемента — старт по факту правки. Здесь нужна осторожность: если не поставить условие, процесс будет запускаться при каждом сохранении и плодить дубли. Это самая частая ошибка новичков.
Запуск по расписанию штатно у процессов отсутствует — регулярность обычно решается повторяющейся задачей, которая напоминает человеку запустить процесс, либо созданием элемента списка по расписанию.
Отдельный сценарий — запуск процесса роботом из CRM. Сделка доходит до нужной стадии, робот стартует процесс согласования, и дальше маршрут ведёт уже он. Такая связка чаще всего и используется в продажах: линейная часть на роботах, согласования на процессах. Как устроены стадии и роботы в сделках, разобрано в статье сделки в Битрикс24.
Отладка и типичные сбои
Процесс завис на задании. Самая частая ситуация: согласующий в отпуске или уволен, а замены в схеме нет. Лечится назначением согласующего не конкретным человеком, а руководителем подразделения, и добавлением срока с эскалацией.
Процесс запускается по несколько раз. Признак старта при изменении элемента без условия. Нужно либо переводить на запуск при создании, либо добавлять проверку статуса.
Процесс упал на действии с полем. Обычно потому, что поле переименовали или удалили после сборки шаблона. Схема ссылается на внутренний код поля, и любое изменение структуры нужно проверять на процессах.
Задания приходят не тем людям. Причина почти всегда в структуре компании: у сотрудника не указан руководитель, и блок «руководитель инициатора» разрешается в пустоту.
Порядок разбора простой: открыть журнал выполнения конкретного экземпляра процесса, найти последний успешный шаг и смотреть следующий. Журнал показывает, какие значения были в переменных, — этого обычно достаточно, чтобы понять причину без догадок.
Проверять новую схему нужно на тестовом элементе и обязательно по всем веткам, включая отказ и возврат. Ветку отказа забывают проверить чаще всего, а именно она вылезает в первый же рабочий день.
Когда бизнес-процесс не нужен
Не всякую задачу стоит автоматизировать. Если действие одно и без ветвлений — достаточно робота, он проще и надёжнее. Если согласование происходит раз в месяц и участвуют два человека — процесс добавит формальностей больше, чем сэкономит времени.
Не стоит строить процесс и там, где правила ещё не устоялись. Схему придётся переделывать каждую неделю, а сотрудники запомнят, что «в системе всё время всё меняется» — доверие к автоматизации после этого восстанавливается долго.
Наконец, процесс бесполезен, если у шагов нет владельцев. Автоматизация не создаёт ответственность, она её фиксирует. Пока не решено, кто именно согласует и в какой срок, любая схема упрётся в человека, который «не увидел уведомление».
Разумный порядок такой: сначала описать процесс словами и прогнать вручную, затем автоматизировать линейную часть роботами, и только сложные маршруты с ветвлениями переводить в бизнес-процессы. Как этот порядок встраивается в проект внедрения, описано в статье этапы внедрения CRM.
Частые вопросы
Чем бизнес-процесс отличается от робота в Битрикс24?
Робот выполняет одно действие на стадии и не умеет ждать ответа человека. Бизнес-процесс ведёт многошаговый маршрут с ветвлениями, заданиями сотрудникам и возвратом на предыдущий шаг.
Нужно ли программировать, чтобы создать бизнес-процесс?
Нет. Схема собирается в визуальном дизайнере из готовых блоков. Программирование требуется только для нестандартных действий, которых нет среди штатных.
Где можно запускать бизнес-процессы?
В CRM на лидах и сделках, в универсальных списках, на документах Диска и в живой ленте для заявлений и служебных записок.
Почему бизнес-процесс запускается несколько раз?
Обычно потому, что он настроен на старт при изменении элемента без дополнительного условия. Каждое сохранение элемента создаёт новый экземпляр процесса.
Что делать, если процесс завис на согласовании?
Открыть журнал выполнения и посмотреть, на ком остановилось задание. Чтобы это не повторялось, согласующего назначают не конкретным сотрудником, а руководителем подразделения, и добавляют срок с эскалацией.
Где взять шаблоны бизнес-процессов в Битрикс24?
Готовые шаблоны есть для процессов в живой ленте: отпуск, командировка, служебная записка, счёт на оплату. Их удобно брать за основу. Для CRM и универсальных списков шаблоны собираются в дизайнере под задачу, а отлаженную схему можно выгрузить в файл и загрузить в другой список или портал.
Как сделать, чтобы следующий шаг запускался только после выполнения задачи?
Поставить в бизнес-процессе блок задачи с ожиданием её завершения: процесс стоит на этом шаге, пока задачу не закроют, и только потом идёт дальше. Робот CRM так не умеет, поэтому такую цепочку собирают процессом, который запускается роботом на нужной стадии.
Чем параллельное выполнение отличается от последовательного согласования?
При последовательном согласовании участники получают задания по очереди, при параллельном — одновременно, и процесс идёт дальше, когда закончены все ветки. Параллельная схема быстрее, но в ней нужно заранее прописать, что делать, если одна из веток отклонила заявку.