Битрикс24: бизнес-процессы и права — тема, о которой вспоминают, когда что-то уже случилось. Менеджер отменил согласование скидки, стажёр поправил шаблон «на минутку», а заявка на оплату, которую уже утвердили, вдруг изменилась задним числом. Во всех трёх случаях сам процесс был нарисован правильно — неправильно были выданы права.
Разбираю, из каких контуров прав состоит автоматизация в Битрикс24, где настраивается каждый из них, от чьего имени работает процесс и какую схему выдать ролям, чтобы процессы не обходили и не ломали. Общие права доступа к CRM — роли, уровни «свои» и «свои и отдела», запрет экспорта — разобраны отдельно в материале о настройке прав доступа. Здесь — только то, что касается процессов.
Бизнес-процесс не спрашивает, можно ли сотруднику менять поле. Он просто меняет. Поэтому права на процессы важнее прав на карточки.
Четыре вопроса о правах, которые путают между собой
Когда говорят «настроить права на бизнес-процессы», обычно имеют в виду что-то одно из четырёх. Настраивать нужно все четыре, и живут они в разных местах ↓
| Вопрос | Где решается | Что будет, если забыть |
|---|---|---|
| Кто запускает процесс | Права на сам документ: сделку, элемент списка | Процесс запускают не те люди, а нужные не могут |
| Кто меняет шаблон | Доступ к дизайнеру: настройки CRM, управление списком | Логику правят без согласования, процесс ломается тихо |
| Кто получает задания | Настройки конкретного действия в шаблоне | Задание уходит уволенному, и процесс стоит |
| Что процесс делает с доступом | Действие установки прав в шаблоне | Документ после утверждения остаётся открытым на правку |
Дальше — по каждому пункту, а в конце рабочая схема и чек-лист.
Кто может запускать бизнес-процессы
Процессы стартуют тремя путями: вручную из карточки, автоматически при создании или изменении документа и из робота. Подробно способы разобраны в материале о том, как запустить бизнес-процесс. С правами напрямую связан только ручной запуск — и именно там чаще всего ошибаются.
Ручной запуск доступен тому, кто работает с документом: в CRM — сотруднику, который может изменять сделку или другой элемент, в списках — тому, у кого есть доступ к элементам. Отдельной галочки «может запускать процесс X» во многих местах просто нет: право на запуск идёт следом за правом на документ. Отсюда практический вывод: ограничивать запуск проще через права на сам документ и через условия внутри процесса, чем искать настройку, которой не существует.
Автоматический запуск права не проверяет вовсе. Процесс стартует от события — создания или изменения документа, — кто бы это событие ни вызвал. Поэтому автозапуск подходит для того, что должно происходить всегда: уведомить, поставить задачу, проверить заполненность полей. Для того, что должно происходить по решению конкретного человека, он не годится.
Типовой приём для ручного запуска — проверка в первом шаге. Процесс стартует, смотрит, кто его запустил, и если это не тот, кому положено, — завершается с понятным сообщением. Например, запросить скидку выше порога может только старший менеджер: у остальных процесс вежливо откажет и объяснит почему. Это надёжнее, чем прятать кнопку.
Кто может создавать и менять шаблоны
Шаблон — это логика процесса: шаги, условия, кому уходят задания. Право менять шаблон равно праву менять правила компании: поправив одно условие, можно отправить все договоры мимо юриста. Поэтому доступ к дизайнеру держат у двух-трёх человек, а не выдают «всем, кто разбирается».
Кто может править шаблоны, зависит от того, где живёт процесс ↓
Второе правило — не править живой шаблон. Изменения применяются к новым запускам, а процессы, которые уже идут, продолжают работать по прежней логике. После правки в работе одновременно оказываются две версии, и понять, почему одна заявка согласовалась без директора, а другая с ним, становится трудно. Копия шаблона, проверка на тестовой сделке, затем замена — это на полчаса дольше и снимает большинство сюрпризов.
Третье — история изменений. В самом дизайнере её нет в привычном виде, поэтому договоритесь о простом правиле: любое изменение шаблона согласует владелец процесса, а администратор записывает, что и зачем поменял. Хватит комментария в задаче на изменение.
Права исполнителей: кто получает и видит задания
Задание — шаг, на котором процесс ждёт человека: утвердить, ознакомиться, дать недостающие данные. Как такие шаги устроены, разобрано в материале о задании бизнес-процесса. С точки зрения прав здесь три вопроса.
Кому уходит задание. Исполнителя можно указать конкретным человеком, группой, ролью из структуры компании (например, руководитель инициатора) или полем документа — ответственным за сделку. Конкретная фамилия в шаблоне — самый хрупкий вариант: человек уходит в отпуск или увольняется, и процесс встаёт. Надёжнее ссылаться на роль или поле.
Кто видит задание. Само задание видит исполнитель. Ход процесса в карточке видят те, у кого есть доступ к документу. Администратор может посмотреть все запущенные процессы и найти те, что стоят. Если у исполнителя нет доступа к документу, который он согласует, решение он будет принимать вслепую — это стоит проверить отдельно.
Можно ли передать задание. В настройках согласования есть делегирование: передать задание разрешено никому, подчинённым или любому сотруднику. Для согласований с деньгами обычно оставляют передачу только подчинённым: на время отпуска работа не встанет, но и директор не «делегирует» подпись стажёру.
Увольнение и отпуск: что проверить в процессах
Самый частый повод вспомнить о правах на процессы — уход сотрудника. Пользователя блокируют, сделки передают коллеге, а про процессы забывают. Задания, которые уже ушли уволенному, сами никуда не денутся: процесс будет ждать ответа от заблокированной учётной записи.
Порядок действий простой ↓
- Найти задания сотрудника. До блокировки посмотреть, какие процессы ждут его решения.
- Перезапустить зависшие. Остановить процессы и запустить заново с новым исполнителем.
- Проверить шаблоны. Если фамилия стоит в шаблоне исполнителем, заменить её на роль или поле документа.
- Закрыть доступ к дизайнеру, если он у сотрудника был, и проверить, какие шаблоны он менял в последние недели.
С отпуском проще: делегирование подчинённым закрывает большую часть случаев. Но договориться о нём нужно до отпуска, а не в день, когда клиент ждёт согласованный счёт.
От чьего имени работает процесс
Это самая недооценённая часть темы. Действия бизнес-процесса выполняются от имени системы, а не сотрудника, который его запустил. Процесс может изменить поле, которое менеджеру руками менять нельзя, передвинуть сделку на закрытую для него стадию, поставить задачу коллеге из другого отдела.
Это одновременно главная возможность и главная дыра. Возможность — потому что поле «Согласованная скидка» можно закрыть от ручной правки и менять только процессом после утверждения руководителя: тогда цифра в карточке всегда подтверждена. Дыра — потому что процесс, запущенный кем угодно, делает то, что в нём написано. Если в шаблоне есть шаг «изменить ответственного на сотрудника из параметра», то любой, кто может запустить процесс, фактически передаёт сделку кому угодно — даже если в его роли смена ответственного запрещена.
Вывод простой: проверяйте не только роли, но и то, что умеют процессы, доступные этим ролям. Любой шаблон с параметрами на старте — это форма, через которую сотрудник влияет на данные в обход своих прав. Такие параметры стоит перечислить и для каждого ответить на вопрос: что будет, если сюда введут не то.
Как процесс сам управляет правами на документ
В списках и библиотеках документов процесс умеет не только обходить права, но и выставлять их. В дизайнере для этого есть действие установки прав: на каждом шаге можно определить, кто может читать и изменять документ. Вот как это выглядит на заявке на оплату ↓
Права меняются вместе со статусом заявки:
Без установки прав заявку можно поменять уже после утверждения — и подпись руководителя окажется под другой суммой.
В CRM логика другая: права на сделки задаются ролями, и процесс их не переписывает. Похожего эффекта добиваются через стадии и поля. Например, стадию «Оплачено» выставляет только процесс после подтверждения бухгалтера, а ручной переход на неё в ролях закрыт. На старших тарифах права на отдельные стадии и поля настраиваются прямо в ролях CRM.
Права CRM и роботы: где проходит граница
Роботы — упрощённая автоматизация на стадиях сделки — живут по тем же принципам: срабатывают от события и действуют от имени системы. Кто может менять саму автоматизацию на стадиях, определяется правами в CRM, и это право стоит проверить так же внимательно, как доступ к дизайнеру. Оставьте его администратору и руководителю, который отвечает за процесс продаж: робот, выключенный менеджером «потому что мешал», — частая причина того, что клиенту перестали уходить напоминания.
Когда что выбирать — роботов или процесс, — разобрано в обзоре бизнес-процессов в Битрикс24. Для темы прав важно одно: многоступенчатые согласования с передачей заданий и сменой доступа по шагам удобнее строить процессом. Роботы для этого слишком простые, и разграничение доступа на них превращается в набор костылей из полей и стадий.
Рабочая схема прав для бизнес-процессов
Схема ниже подходит большинству компаний малого и среднего бизнеса. Начните с неё и усложняйте, только когда появится конкретная причина ↓
| Роль | Запуск | Шаблоны | Задания |
|---|---|---|---|
| Менеджер | Свои документы; процессы с проверкой на старте | Нет | Исполнитель по полю «ответственный» |
| Руководитель отдела | Документы отдела | Нет, только заявки на изменения | Согласования, делегирование подчинённым |
| Владелец процесса | Все документы процесса | Согласует изменения | Итоговое утверждение |
| Администратор | Все | Создаёт и правит через копию | Не участвует, следит за зависшими |
Ключевая строка — владелец процесса. Это не технический специалист, а руководитель, который отвечает за результат: финансовый директор — за заявки на оплату, коммерческий — за скидки. Без его согласия логика не меняется. Администратор делает руками, владелец решает.
Типичные ошибки
Всё это видно при разборе чужих порталов — от небольших отделов продаж до компаний с десятком процессов ↓
Разбор автоматизации за 20–30 минут
Посмотрю ваши процессы и роботов: кто может запускать и править шаблоны, куда уходят задания, где процесс даёт обойти роли. Без отдела продаж — говорите с тем, кто делает проекты руками.
Записаться на разбор →Чек-лист проверки прав на процессы
Пройдите его на своём портале — уходит полчаса ↓
- Доступ к дизайнеру у двух-трёх человек, и вы знаете каждого по имени.
- У каждого процесса назван владелец, без согласия которого шаблон не меняется.
- Исполнители заданий указаны ролью или полем документа, а не фамилией.
- Параметры на старте проверены: ни один процесс не даёт сменить ответственного или сумму в обход ролей.
- Утверждённые документы закрыты от правки — установкой прав в списках или стадиями в CRM.
- Зависшие задания проверяются раз в неделю — особенно после увольнений и отпусков.
Проверять лучше глазами сотрудника: зайдите под ролью менеджера, запустите процесс, попробуйте изменить документ после утверждения. Десять минут такого теста находят больше, чем час чтения настроек.
Итог: права в бизнес-процессах Битрикс24 — это не одна галочка, а четыре контура: запуск, шаблоны, задания и доступ к документу. Процесс сильнее прав сотрудника, поэтому проверять надо не только роли, но и то, что умеют процессы. Технические детали отдельных действий — в справке Битрикс24. Если процессов много и никто уже не помнит, кто что может, — это задача для разбора автоматизации, а стоимость внедрения с нуля покажет калькулятор.