Права в бизнес-процессах Битрикс24: кто видит процесс, кто запускает и кто меняет шаблон

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

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

В Битрикс24 права в бизнес-процессах устроены как несколько независимых слоёв, и путать их — главная причина ошибок. Первый слой — доступ к самому шаблону процесса: кто его видит в списке и кто может открыть дизайнер. Второй — право запускать процесс, то есть создавать новые экземпляры по этому шаблону. Третий — доступ к уже запущенным экземплярам: просмотр, изменение, удаление элементов и стадий. Четвёртый — редактирование шаблона: изменение структуры, стадий, заданий и прав.

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

Отдельно стоит слой элементов: просматривать элементы могут любые пользователи, создавать — только указанные в разделе запуска, а изменять и удалять — те, у кого есть право на создание. Комментарии в таймлайне читают и добавляют любые сотрудники, но править и удалять комментарий может только его автор. Эти четыре слоя и определяют, как выглядит корректная настройка бизнес процессов в Битрикс 24.

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

Исходные данные, которые нужны до настройки

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

Далее — матрица «роль → что должна делать». Для каждой роли зафиксируйте три ответа: видит ли она шаблон, запускает ли процесс, правит ли шаблон. Часто выясняется, что роль, которая запускает процесс, не должна его редактировать, и наоборот. Это нормальная ситуация, и её нужно отразить в настройках.

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

Четвёртый пункт — тариф. Настройка прав доступа в задачах доступна не на всех тарифах (требуется «Профессиональный» или «Энтерпрайз»), и это стоит проверить до начала работ. Если вы настроили права и перешли на тариф ниже, настройки продолжат работать по этим правилам, но изменить их можно будет только на подходящем тарифе. Уточняйте актуальные условия по своему тарифу в справке или у своего партнёра по внедрению. Обратите внимание: права в бизнес-процессах (роботах) могут иметь другие ограничения по тарифам, чем права в задачах.

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

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

Вторая схема — «ролевой запуск»: запуск ограничен конкретными отделами или должностями, правка — ещё уже. Подходит, когда процесс затрагивает чувствительные данные и запускать его должен не каждый. Третья схема — «полный доступ для команды процесса»: небольшая команда и видит, и запускает, и правит. Подходит для пилотных процессов, которые ещё дорабатываются.

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

Не пытайтесь выдать всем полный доступ «чтобы не мешало». Это самый частый источник случайных изменений. В документации указано: права помогают предотвратить потерю данных и внесение изменений в процессы, и разумно разрешать редактирование и удаление только тем, у кого есть опыт настройки.

Предметная последовательность настройки доступа

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

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

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

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

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

Таблица решений: роль, шаблон, запуск, правка

Таблица ниже — рабочий артефакт. Заполните её под свою компанию и согласуйте с владельцем процесса до внесения настроек. Строки условные, но структура отражает реальные слои доступа.

Обратите внимание на строку «Исполнитель»: он видит шаблон и работает со стадиями, но не запускает новые экземпляры и не правит дизайн. Строка «Инициатор заявки» запускает процесс, но не влияет на его структуру. Такое разделение снимает большинство конфликтов.

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

Как проверить настройку до запуска в работу

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

Первый сценарий — запуск. Войдите под учётной записью инициатора и убедитесь, что процесс запускается. Затем войдите под учётной записью исполнителя и проверьте, что запуск недоступен, если так задумано. Наблюдаемый результат — кнопка запуска либо есть, либо её нет, и это видно сразу.

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

Четвёртый сценарий — удаление. Убедитесь, что удалить процесс может только тот, у кого есть право на изменение, и только когда в процессе нет элементов. Пятый — комментарии: проверьте, что чужой комментарий нельзя отредактировать. Результаты прогона фиксируйте письменно: кто проверял, под какой ролью, что наблюдалось.

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

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

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

Проверка показала следующее. Инициатор из первого отдела успешно создал заявку. Исполнитель из второго отдела не смог запустить процесс — как и задумано. Руководитель отдела провёл согласование и перевёл стадию. Попытка исполнителя изменить шаблон не удалась. Удаление тестового процесса прошло только после того, как из него убрали все элементы, включая завершённые.

Наблюдаемый результат: заявки создаются без задержек, структура процесса защищена от случайных правок, стадии двигают только ответственные. Ответственный за настройку — технический исполнитель, владелец процесса согласовал матрицу ролей. Данные о компании и количестве объектов условные и не являются статистикой.

Типичные ошибки и ограничения

Первая ошибка — выдать полный доступ «чтобы работало». Это открывает правку шаблона всем и сводит защиту к нулю. Вторая — не указать ответственных за задания и удивиться, что стадии двигает кто угодно. Третья — назначить сотруднику несколько ролей и получить пересечение с максимальными правами.

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

Ограничения тоже стоит проговорить. Администратор портала обходит любые настройки, поэтому права не защищают от него. Логика доступа к элементам и стадиям зависит от конкретных настроек процесса, и её нужно проверять на тестовой копии, а не предполагать. Возможности роботов, триггеров и смарт-процессов зависят от тарифа, и универсального ответа «работает везде» здесь нет.

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

Чек-лист приёмки

• Собрана карта ролей и матрица «роль → шаблон → запуск → правка»
• Назначен владелец процесса и технический исполнитель
• Проверен тариф на доступность нужных настроек прав
• Редакторы шаблона ограничены узким кругом
• Запуск настроен под реальных инициаторов, а не «для всех»
• Ответственные за задания указаны явно, стадии не открыты произвольно
• Пересечения ролей проверены, лишние роли не выданы
• Прогон проведён на тестовой копии, а не на рабочем процессе
• Проверены сценарии запуска, правки, стадий, удаления и комментариев
• Результаты прогона зафиксированы письменно
• Есть план возврата: как откатить настройки, если что-то пойдёт не так

Что делать дальше

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

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

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