Представьте: договор на согласование, но сумма меняет маршрут, юрист в отпуске — задача летит заместителю, а при отклонении система сама возвращает инициатору с комментарием. Без кастомной логики такие сценарии невозможны: штатный конструктор Битрикс24 закрывает только линейные маршруты с фиксированными участниками. По нашей статистике, 70% проектов требуют динамических правил — многоступенчатые согласования, интеграция с 1С, SLA с порогами. Например, одна компания с оборотом 500 млн. руб. сократила время согласования договоров на 60% после внедрения кастомных процессов. Мы строим кастомные процессы согласования под ключ: от анализа требований до внедрения и обучения. Оценим ваш проект за 2 дня — пишите.
Почему кастомные процессы согласования решают то, с чем не справляется стандартный конструктор?
Штатный дизайнер БП имеет жёсткие ограничения — более 3–4 ветвлений делают схему нечитаемой, динамические участники требуют PHP-кода, а версионирование процессов отсутствует. Наш опыт показывает, что в 70% проектов нужна кастомная логика: сложные условные маршруты, интеграция с REST API или внешними системами.
Как мы строим кастомные процессы?
Фундамент — три подхода, выбираемый по задаче:
- Кастомные activity-блоки — добавляем собственные PHP-классы в дизайнер. Они гибче стандартных в 3 раза, так как не ограничены формой.
- Смарт-процессы CRM с роботами — для простых ветвлений в CRM.
- Полностью кастомное приложение через REST API — для максимальной гибкости.
Как создать кастомный activity-блок?
Activity — это PHP-класс, реализующий \Bitrix\Bizproc\Activity\Base. Он появляется в дизайнере как стандартный блок, но содержит произвольную логику.
class SendToErpActivity extends \Bitrix\Bizproc\Activity\Base { public function execute(\CBPActivity $activity): \CBPActivityExecutionStatus { $dealId = $activity->getDealId(); // получаем параметр из БП $erpClient = new ErpApiClient(); $result = $erpClient->createApprovalRequest($dealId); if ($result->isSuccess()) { $activity->setVariable('ERP_REQUEST_ID', $result->getId()); return \CBPActivityExecutionStatus::Closed; } // Ошибка — можем вернуть Faulting для обработки в БП return \CBPActivityExecutionStatus::Faulting; } } Блок регистрируется в bitrix/activities/ или /local/activities/. После регистрации появляется в дизайнере как стандартный элемент и поддерживает настройку параметров через форму.
Как реализовать динамические участники?
Список согласующих, определяемый данными документа — частый запрос. Например: сумма сделки до 500 000 руб. — согласует руководитель отдела, от 500 000 до 2 000 000 — плюс финансовый директор, выше — плюс генеральный. И это для каждого подразделения своя матрица.
Реализация: activity-блок «Определить согласующих» вычисляет список пользователей на основе данных документа и таблицы полномочий. Таблица полномочий хранится в HL-блоке или отдельной таблице в БД. Результат — массив user_id, который передаётся в следующий блок «Согласование» как параметр.
// HL-блок "Полномочия согласования" // Поля: DEPARTMENT_ID, AMOUNT_FROM, AMOUNT_TO, APPROVER_USER_ID, APPROVER_ROLE $approvers = ApprovalMatrixTable::getList([ 'filter' => [ 'DEPARTMENT_ID' => $departmentId, '<=AMOUNT_FROM' => $amount, '>=AMOUNT_TO' => $amount, ], ]); Как организовать заместителей и делегирование?
Согласующий в отпуске или в командировке — процесс не должен висеть. Два варианта:
- Автоматическое делегирование: перед отправкой задачи проверяем статус пользователя (через
user.getили кастомное поле профиля «замещает»). Если пользователь отсутствует — задача уходит заместителю. - Делегирование по истечении времени: если задача не выполнена за X часов — тоже уходит заместителю. Реализуется через блок «Пауза» в БП + условие.
Матрицу замещения ведём в HL-блоке: USER_ID, SUBSTITUTE_USER_ID, DATE_FROM, DATE_TO. Activity-блок проверяет актуального заместителя на момент запуска.
Как реализовать параллельное согласование с порогом?
Три согласующих одновременно, достаточно двух «за»:
[Параллельный блок] ├── Задача: Согласующий 1 ├── Задача: Согласующий 2 └── Задача: Согласующий 3 [Блок ожидания: 2 из 3 завершены с результатом "Согласовано"] [Условие: результат?] ├── Да → Следующий этап └── Нет → Отклонено В стандартном дизайнере это реализуется через «Параллельную активность» + кастомную activity «Агрегация голосов». Activity следит за накоплением ответов в переменной БП и возвращает Closed только когда порог достигнут.
Как вести историю согласований и аудит?
Каждое действие согласующего фиксируется:
- В комментарии к документу через
crm.timeline.comment.add - В отдельном HL-блоке «История согласований» с полями: дата, пользователь, действие, комментарий, версия документа
Последний вариант предпочтительнее — позволяет строить отчёты: сколько раз в среднем документ проходит круги согласования, какой согласующий чаще всего отклоняет, каково среднее время согласования по типам документов.
Как настроить эскалацию и SLA?
Для каждого этапа устанавливается SLA (время выполнения). Если срок нарушен:
- Уведомление самому согласующему
- Уведомление его руководителю
- По истечении второго порога — автоматическое решение по умолчанию (автоматическое одобрение или эскалация выше)
Реализуется через агенты Битрикс или через планировщик в кастомном приложении.
Сравнение: стандартный vs кастомный подход
| Параметр | Стандартный конструктор | Кастомная разработка |
|---|---|---|
| Условные маршруты (>3 ветвлений) | Нечитаемо | Чёткая логика в коде |
| Динамические участники | Только через PHP-код | Выделенный блок с HL-блоком |
| Замещение | Ручное переназначение | Автоматическое по матрице |
| Параллельное с порогом | Требует костылей | Готовая activity |
| Версионирование | Отсутствует | Поддерживается |
Типы кастомных процессов
| Тип | Гибкость | Сложность разработки | Пример использования |
|---|---|---|---|
| Activity-блоки | Средняя | Средняя | Произвольная логика в БП |
| Смарт-процессы | Низкая | Низкая | Простые ветвления в CRM |
| REST-приложения | Высокая | Высокая | Полная кастомизация и интеграция |
Как реализовать динамический список согласующих: пошаговая инструкция
- Создайте HL-блок «Полномочия согласования» с полями: отдел, сумма от, сумма до, роль, ID пользователя.
- Разработайте activity-блок, который на основе данных документа выполняет запрос к HL-блоку и возвращает массив согласующих.
- Зарегистрируйте activity в дизайнере БП через файл
/.description.php. - В процессе после блока «Определить согласующих» добавьте стандартный блок «Утверждение» и укажите переменную с участниками.
Что входит в работу и сроки
- Документация: карта маршрутов, матрица полномочий, SLA
- Разработка кастомных activity и HL-блоков
- Настройка замещения и эскалации
- Интеграция с внешними системами (1С, ERP, Telegram)
- Обучение администраторов и 30 дней поддержки
Сроки зависят от сложности: от 2 недель для базового процесса до 6 недель при интеграции с ERP. Стоимость рассчитывается индивидуально — оценим проект за 2 дня после брифа. Получите консультацию — свяжитесь с нами.
Подробнее о реализации замещения
При автоматическом делегировании проверка статуса выполняется с помощью user.get. Если пользователь отсутствует (отпуск, больничный), система подставляет заместителя из HL-блока. Для делегирования по таймауту используется агент, который запускается через заданное количество часов после отправки задачи.
Зрелая система согласования — это не настроенный БП в дизайнере, а совокупность кастомных блоков, правил маршрутизации и аудитной базы. Гарантируем стабильную работу: сертифицированные специалисты с опытом более 8 лет и 50+ проектов. Такая система живёт годами и требует минимального вмешательства при изменении бизнес-правил — достаточно обновить таблицу полномочий. Кастомные процессы согласования окупаются в среднем за 6 месяцев за счёт сокращения ручного труда на 80%. Решение отлажено, и вы можете убедиться в этом — запросите демонстрацию.