Менеджер по продажам открывает CRM и видит сделки всех отделов компании — финансовые показатели, клиентов конкурирующих менеджеров, переписку, которая его не касается. Кроме лишнего шума это создаёт реальный риск: при увольнении сотрудник уносит в голове куда больше информации, чем должен был иметь доступ. Настройка прав доступа в Bitrix24 решает это — каждый видит ровно то, что нужно для его роли, не больше.
В статье разберём, как настроить права доступа в Bitrix24: от готовых ролей до тонкой настройки видимости по отделам и типам данных. Материал для ЛПР (лиц, принимающих решения) и руководителей, которым нужно разграничить доступ сотрудников без привлечения разработчика.
Что понадобится перед началом
- Доступ к Bitrix24 с правами администратора портала
- Структура компании: отделы, должности, кто кому подчиняется (без этого правильно настроить иерархию прав невозможно)
- Список типов данных, к которым нужно ограничить доступ (сделки, лиды, контакты, отчёты, финансовые поля)
- Понимание, какие сотрудники должны видеть только свои данные, а какие — данные всего отдела
Основная часть: настраиваем права доступа
Шаг 1. Разбираемся со структурой ролей в Bitrix24
Права доступа в Bitrix24 строятся на основе ролей CRM — это шаблоны разрешений, которые потом назначаются сотрудникам или отделам. По умолчанию есть несколько готовых ролей (например, «Менеджер по продажам», «Руководитель отдела продаж»), но их можно редактировать и создавать свои.
Параллельно существует организационная структура компании (отделы, подчинённость), которая настраивается в разделе «Компания» → «Структура компании» — её обязательно нужно настроить до перехода к правам, потому что многие правила завязаны именно на иерархию («видит подчинённых», «видит свой отдел»).
Частая ошибка: настраивают права доступа, не выстроив структуру компании в системе. В результате правила вроде «руководитель видит сделки своего отдела» не работают, потому что Bitrix24 не понимает, кто в каком отделе.
Шаг 2. Открываем раздел настройки прав
Идём в «Настройки» → «Права доступа» → «Настройка прав доступа». Здесь отображается таблица: роли в столбцах, типы CRM-сущностей (лиды, сделки, контакты, компании) в строках, и уровень доступа в ячейках.
Шаг 3. Настраиваем уровень видимости для каждой роли
Для каждой роли и каждого типа данных можно выбрать один из уровней: «Все», «Отдел и подчинённые отделы», «Свой отдел», «Личные» (только свои записи), «Запрещено». Например, для роли «Менеджер по продажам» обычно ставят «Личные» на чтение чужих сделок и «Все» только на свои.
Частая ошибка: ставят всем менеджерам уровень «Все» «на всякий случай, чтобы не дёргали с вопросами доступа». Это снимает технические неудобства сразу, но создаёт риск утечки данных и усложняет анализ персональной эффективности — невозможно понять, кто реально ведёт сделку.
Шаг 4. Настраиваем права на действия, а не только на просмотр
Отдельно от видимости настраивается право на действия: создание, изменение, удаление записей. Например, обычному менеджеру стоит запретить удаление сделок — это действие лучше оставить только руководителю отдела или администратору, чтобы случайное нажатие не привело к потере данных.
Настраивается в той же матрице прав, но в отдельных столбцах для каждого типа действия (просмотр, добавление, изменение, удаление).
Шаг 5. Ограничиваем доступ к финансовым полям
Если не все сотрудники должны видеть суммы сделок или маржинальность, можно настроить видимость конкретных полей на уровне карточки — раздел «Настройки» → CRM → «Видимость и обязательность полей» для нужной роли. Например, менеджер по продажам видит сумму сделки, но не видит себестоимость, если это отдельное поле.
Частая ошибка: считают, что скрытие поля в интерфейсе полностью защищает данные. Если у сотрудника есть доступ к экспорту данных или к API через свой аккаунт, скрытое в интерфейсе поле может быть доступно другим способом. Решение: для действительно чувствительных данных дополнительно ограничивать права на экспорт и доступ к REST API.
Шаг 6. Настраиваем права для внешних сотрудников и подрядчиков
Если в компании работают удалённые подрядчики или временные сотрудники, для них стоит создавать отдельную роль с минимальным набором прав — например, видимость только конкретных сделок, к которым они привязаны, без доступа к остальной базе клиентов.
Шаг 7. Тестируем права на тестовом аккаунте
Создаём тестового пользователя с нужной ролью (или временно входим под учётной записью реального сотрудника с его разрешения) и проверяем, что видимость данных соответствует ожиданиям. Лучше потратить 10 минут на проверку, чем обнаружить утечку данных постфактум.
Частые ошибки и как их избежать
Ошибка: права настраиваются один раз и больше не пересматриваются. Когда сотрудник переходит в другой отдел или меняет должность, его права в CRM часто забывают обновить — он продолжает видеть данные старой роли. Решение: включить проверку прав доступа в чек-лист при любом кадровом изменении.
Ошибка: руководитель отдела не видит сделки своих подчинённых, потому что роль настроена на уровень «Личные» вместо «Отдел и подчинённые». Возникает из путаницы между похожими уровнями доступа. Решение: после настройки явно проверить с самим руководителем, видит ли он то, что должен.
Ошибка: слишком жёсткие права мешают сотрудникам выполнять работу, и они начинают просить администратора расширить доступ точечно, бессистемно. Со временем матрица прав превращается в хаос из исключений. Решение: пересматривать роли целиком при накоплении исключений, а не точечно патчить права под каждый отдельный случай.
Итог
После этой настройки каждый сотрудник видит и может изменять ровно те данные, которые соответствуют его роли — без избыточного доступа и без риска случайной утечки чужих данных. Если на каком-то шаге застряли — опишите ситуацию в комментарии или напишите нам напрямую.