Бизнес-процессы в списках Битрикс24: карта данных и запуск без потери полей

Чтобы запустить бизнес-процесс из элемента списка в Битрикс24, сначала включают поддержку бизнес-процессов в настройках списка, затем настраивают сам процесс и привязывают поля элемента к переменным. Главный риск — потеря или рассинхронизация данных, если поля списка и переменные процесса не совпадают по смыслу и моменту чтения. Ниже — карта данных «поле списка → переменная процесса → шаг чтения/записи», порядок действий, таблица выбора, чек-лист и учебный пример.

Что именно автоматизируют бизнес-процессы в списках Битрикс24

Бизнес-процессы в списках Битрикс24 автоматизируют обработку элементов: согласование, регистрацию, выдачу, приёмку. Список здесь — хранилище записей, а процесс — последовательность шагов с ролями и статусами. Элемент списка становится «заявкой», которая проходит по маршруту.

Границы задачи важно зафиксировать до настройки. В типовом сценарии вы включаете поддержку бизнес-процессов в конкретном списке, создаёте или выбираете процесс, описываете шаги, назначаете ответственных и правила переходов. Вне границ — замена сотрудников, гарантии по срокам и утверждения, что все функции доступны на любом тарифе. Набор возможностей зависит от редакции Битрикс24 и от того, какие инструменты автоматизации уже подключены в вашем портале.

Отдельно проверьте, как в вашем портале устроены списки: это может быть раздел «Списки» или перенесённый в бизнес-процессы список. Справка Битрикс24 указывает: перенос списка в бизнес-процессы сохраняет элементы, но обратный перенос невозможен. Действие необратимо, поэтому решение о переносе принимают осознанно.

Ещё одно ограничение из справки: один и тот же элемент не может участвовать более чем в двух процессах одновременно. Это влияет на проектирование: если по одной заявке нужно запускать несколько маршрутов, продумайте, как разделить их по времени или по отдельным элементам.

Практический результат грамотной настройки — предсказуемый маршрут: понятно, кто читает поле, кто его меняет, на каком шаге и что видит инициатор. Если этот результат не нужен, автоматизация превращается в лишние клики.

Исходные данные и ответственные за настройку

Перед настройкой соберите входные данные. Без них процесс получится «на глаз» и развалится на первом же исключении.

Что нужно подготовить:

• перечень полей списка с типами (строка, число, дата, список значений, файл, сотрудник);
• описание маршрута: шаги, роли, условия перехода, точки возврата;
• перечень событий, которые должны запускать процесс: создание элемента, изменение поля, ручной запуск;
• список исключений: отказ, возврат на доработку, отмена, повторный запуск;
• ответственных: кто настраивает, кто принимает результат, кто дежурит по ошибкам.

Роли в проекте обычно такие. Владелец процесса отвечает за смысл маршрута и правила. Администратор портала или назначенный настройщик — за техническую конфигурацию списка и процесса. Руководитель подразделения подтверждает, что шаги соответствуют реальной работе. Сотрудник, который будет работать с элементами, проверяет удобство на тестовом элементе.

Важно заранее договориться о терминах. «Согласовано» в списке и «согласовано» в процессе должны означать одно и то же. Если в списке статус — это просто текст, а в процессе — стадия маршрута, их нужно согласовать, иначе возникнет путаница.

Если в компании уже есть настроенные бизнес-процессы и роботы, новые списки стоит вписывать в существующую логику, а не создавать параллельную. Это снижает число дублей и упрощает поддержку.

Варианты запуска и критерии выбора

Запуск процесса из элемента списка можно организовать по-разному. Выбор зависит от того, кто и когда инициирует работу, насколько важен контроль и как часто меняются данные.

Основные варианты:

• ручной запуск из элемента — сотрудник сам стартует процесс, когда заявка готова;
• запуск при создании элемента — процесс стартует автоматически для каждой новой записи;
• запуск по изменению поля — процесс стартует, когда поле достигает нужного значения;
• запуск по расписанию или внешнему событию — если маршрут привязан к календарю или действию в другом разделе.

Критерии выбора: предсказуемость момента старта, число лишних запусков, простота объяснения сотрудникам, возможность отмены и повторного запуска. Ручной запуск даёт контроль, но зависит от дисциплины. Автоматический — снижает ручную работу, но требует аккуратных условий, иначе процесс будет стартовать там, где не нужен.

Сравнение удобно свести в таблицу решений. Она поможет выбрать вариант под конкретный список, а не «по привычке».

Если в портале используются триггеры для переходов в CRM и задачах, проверьте, не дублируют ли они запуск процесса. Два механизма на одно событие — частая причина двойных задач.

Карта данных: поле списка → переменная процесса → шаг чтения/записи

Карта данных — главный рабочий артефакт. Она показывает, какое поле списка попадает в какую переменную процесса и на каком шаге читается или записывается. Без карты настройка превращается в угадывание.

Как её построить:

1. Выпишите все поля списка, которые участвуют в маршруте. 2. Для каждого поля определите переменную процесса и её тип. 3. Отметьте шаг, где переменная только читается, и шаг, где записывается. 4. Укажите, что происходит с полем, если пользователь изменит его во время выполнения. 5. Отдельно отметьте поля, которые не должны меняться после старта.

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

Запись тоже требует внимания. Если два шага пишут в одно поле, порядок записи определяет итог. Если шаг пишет в поле, которое кто-то правит вручную, возможна перезапись. Поэтому в карте данных фиксируют владельца поля: кто имеет право его менять.

Карту удобно вести как таблицу и хранить рядом с регламентом. При изменении маршрута её обновляют первой, а потом уже правят настройки.

Последовательность настройки: от включения до первого запуска

Порядок действий снижает риск ошибок. Сначала включают поддержку, потом настраивают процесс, затем привязывают поля и только после этого запускают тестовый элемент.

Шаги:

• Откройте нужный список и в меню действий выберите настройку списка.
• Активируйте опцию поддержки бизнес-процессов.
• Перейдите к настройке бизнес-процессов и создайте или выберите процесс.
• Опишите шаги, роли и условия переходов.
• Свяжите поля элемента с переменными процесса по карте данных.
• Определите, что происходит при изменении элемента во время выполнения.
• Проверьте права: кто видит элемент, кто может его менять, кто запускает процесс.
• Создайте тестовый элемент и прогоните полный цикл.
• Зафиксируйте результат и только потом переводите настройку в рабочий режим.

После включения опции доступ к настройке бизнес-процессов осуществляется через пункт «Настроить бизнес-процессы». Точные названия пунктов меню могут отличаться в зависимости от версии интерфейса, поэтому сверяйтесь с актуальной справкой вашего портала.

Если в процессе участвуют роботы, посмотрите подход к настройке сценариев и проверке результата, чтобы не дублировать действия процесса и робота.

Что происходит при изменении элемента во время выполнения

Это самый частый источник путаницы. Пользователь меняет поле, пока процесс уже идёт, и ожидает, что маршрут «увидит» новое значение. На практике всё зависит от того, как настроены чтение и запись.

Возможные ситуации:

• процесс прочитал значение на старте и дальше использует его — правка поля на маршрут не влияет;
• процесс читает поле на конкретном шаге — тогда изменение до этого шага будет учтено;
• процесс записывает в поле — ручная правка может быть перезаписана;
• поле защищено от изменений — пользователь не сможет его поправить, пока идёт процесс.

Что делать, чтобы не потерять данные:

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

Повторный запуск — отдельная тема. Если процесс уже завершён, а заявка вернулась, нужно решить: запускать новый процесс по тому же элементу или создавать новый элемент. Обратите внимание: завершённый процесс может занимать одну из двух доступных слотов. Помните про ограничение: элемент не может участвовать более чем в двух процессах одновременно. Если по одному элементу уже идут два процесса, третий не стартует.

Ручное вмешательство тоже нужно регламентировать. Кто имеет право остановить процесс, вернуть на шаг назад, изменить ответственного? Без ответа на эти вопросы маршрут будет ломаться при первом же нестандартном случае.

Матрица проверок перед запуском в работу

Перед тем как перевести настройку в рабочий режим, прогоните матрицу проверок. Она показывает, где маршрут может дать сбой.

Матрица — не формальность. Она экономит время на разборе инцидентов и делает настройку объяснимой для команды.

Учебный пример: заявка на закупку оборудования

Учебный пример. Данные условные, компания и количество объектов вымышлены. Показываем логику, а не реальный кейс.

Входные условия. Есть список «Заявки на закупку» с полями: «Номер», «Инициатор», «Сумма», «Категория», «Статус», «Комментарий согласующего». Нужно, чтобы заявка проходила согласование руководителя и финансового контроля, а при сумме выше порога добавлялся дополнительный шаг.

Действия:

• Включаем поддержку бизнес-процессов в списке.
• Создаём процесс с шагами: «Проверка инициатора», «Согласование руководителя», «Финансовый контроль», «Завершение».
• По карте данных связываем: «Сумма» → переменная суммы (чтение на шаге финансового контроля), «Категория» → переменная категории (чтение на старте), «Статус» → переменная статуса (запись на каждом шаге), «Комментарий согласующего» → переменная комментария (запись на шаге согласования).
• Определяем, что «Сумма» и «Категория» после старта не меняются, а «Комментарий согласующего» может дополняться.
• Настраиваем условие: если сумма выше порога, добавляется шаг дополнительного согласования.
• Проверяем права: инициатор видит свою заявку, согласующие — только назначенные им.

Проверка. Создаём тестовую заявку с суммой ниже порога и прогоняем цикл. Затем меняем сумму в тестовой заявке после старта и убеждаемся, что процесс использует значение на момент чтения, а не новое. Создаём вторую заявку с суммой выше порога и проверяем, что появляется дополнительный шаг. Моделируем отказ на шаге согласования и смотрим, возвращается ли заявка инициатору и что происходит со статусом.

Наблюдаемый результат. Маршрут проходит предсказуемо, статусы меняются по шагам, комментарии сохраняются, повторный запуск по тому же элементу не нарушает лимит в два процесса. Если что-то расходится с картой данных, правим сначала карту, потом настройки.

Чек-лист приёмки настройки

• Поддержка бизнес-процессов включена в нужном списке.
• Карта данных заполнена: поле → переменная → шаг чтения/записи.
• Критичные поля защищены от правки после старта или описано их повторное чтение.
• Роли и права проверены от имени разных участников.
• Условия запуска не создают лишних срабатываний.
• Исключения (отказ, возврат, отмена) описаны и проверены.
• Правило повторного запуска зафиксировано.
• Лимит в два процесса на элемент учтён.
• Тестовый элемент пройден полностью.
• Ответственный за поддержку назначен.
• Регламент для сотрудников обновлён.
• План возврата к прежней настройке есть.

Ограничения, типичные ошибки и следующий шаг

Ограничения. Набор возможностей зависит от редакции Битрикс24 и подключённых инструментов. Не все функции доступны на любом тарифе — это проверяют в конкретном портале. Перенос списка в бизнес-процессы необратим. Элемент не может участвовать более чем в двух процессах одновременно. Точные названия пунктов меню и поведение интерфейса сверяйте с актуальной справкой.

Типичные ошибки:

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

Следующий шаг. Если настройка кажется объёмной, начните с одного списка и одного маршрута. Опишите карту данных, прогоните тестовый элемент, зафиксируйте регламент. Когда логика станет понятной, расширяйте на другие списки. Для комплексной настройки ролей, стадий, событий и исключений можно обратиться к услуге автоматизация бизнес-процессов в Битрикс24.