Права доступа в Битрикс24

Зачем бизнесу настраивать права

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

В Битрикс24 нет одного переключателя, который закрывает всё сразу. CRM, документы CRM, задачи, Диск, проекты и отдельные инструменты имеют собственные настройки. Поэтому рабочая модель строится от процессов и ролей, а не от фамилий сотрудников.

Сначала составьте карту доступа

Не начинайте с интерфейса. Выпишите объекты: лиды, сделки по каждой воронке, контакты, компании, суммы, документы, задачи, файлы, отчёты и настройки. Для каждого объекта укажите действия: читать, создавать, изменять, удалять, импортировать и экспортировать.

Затем определите деловой минимум. Например, менеджер читает и меняет свои сделки, видит контакты своих клиентов, не удаляет элементы и не экспортирует базу. Руководитель отдела работает со сделками отдела и видит суммы. Коммерческий директор читает все продажи, но не обязан управлять системными настройками. Администратор настраивает портал, однако эта роль не должна автоматически принадлежать каждому руководителю.

Матрица ролей для отдела продаж

Менеджер: свои лиды и сделки; создание и изменение разрешены; удаление и экспорт закрыты; переходы доступны только по рабочему маршруту.

Руководитель отдела: элементы своего отдела и подчинённых подразделений; чтение всех полей, контроль стадий и перераспределение ответственных; экспорт — только при подтверждённой необходимости.

Бухгалтер: счета, акты и необходимые реквизиты; сделки доступны на чтение в объёме, нужном для оплаты; изменение цен, стадий и клиентской базы закрыто.

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

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

Как настроить права CRM

В актуальной веб-версии путь указан так: CRM → Ещё → Настройки → Права доступа к CRM. Настраивать раздел может администратор или сотрудник с разрешением изменять настройки CRM. Ролевая модель доступна не на всех тарифах, поэтому до проектирования проверьте возможности лицензии.

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

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

Отдельно ограничьте экспорт, удаление, изменение настроек и роботов. Эти действия влияют не на одну сделку, а на массив данных или логику процесса. Право изменять настройки CRM фактически открывает управление настройками и правами, поэтому выдавать его «для удобства» опасно.

Не забудьте про другие разделы

Документы CRM имеют отдельные роли: можно разделить просмотр документов, изменение и работу с шаблонами. Это защищает реквизиты и утверждённые формы от случайной правки.

В задачах роль участника — постановщик, исполнитель, соисполнитель или наблюдатель — определяет участие, но сама по себе не заменяет настройку прав. Отдельно решите, кто может изменять и удалять задачи и шаблоны.

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

Пошаговый порядок внедрения

1. Утвердите карту объектов и действий с владельцами процессов.
2. Приведите структуру компании в соответствие с фактическим подчинением.
3. Создайте минимальное число функциональных ролей, начиная с наиболее ограниченной.
4. Настройте общие права на элемент, затем исключения по воронкам и стадиям.
5. Отдельно проверьте удаление, экспорт, импорт, роботов, суммы и системные настройки.
6. Назначьте роли отделам или сотрудникам и проверьте пересечения.
7. Войдите под тестовыми пользователями каждой роли и выполните реальные сценарии: создание, смену стадии, передачу сделки, формирование документа, задачу и открытие файла.
8. Зафиксируйте владельца модели и пересматривайте права при переводе, увольнении или изменении процесса.

Почему права работают не так, как ожидалось

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

Для стадии задано отдельное детализированное правило. Оно важнее общего наследуемого права. Проверяйте не только строку элемента, но и каждую стадию, где возникает проблема.

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

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

Ограничения и риски

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