Настройка ролей в CRM Битрикс24
Роли в CRM Битрикс24 — не просто набор галочек в интерфейсе. Это операционная модель, которая определяет, как команда продаж работает с данными: кто видит чужие сделки, кто может экспортировать базу контактов, кто имеет право менять ответственного. Неправильно выстроенные роли приводят либо к избыточным правам («все видят всё»), либо к постоянным запросам на помощь администратору.
Структура роли в CRM
Каждая роль определяет права по двум измерениям: тип операции × область видимости.
Типы операций: чтение, добавление, изменение, удаление, экспорт, импорт, просмотр отчётов.
Области видимости:
-
--— нет доступа -
A— только свои записи -
B— свои + подчинённых -
C— своё подразделение -
D— подразделение + дочерние -
X— все записи
Это важно: область B работает только если в структуре компании корректно выстроена иерархия руководитель–подчинённый. Без неё ведёт себя как A.
Проектирование ролей под бизнес-процессы
Ошибка большинства настроек — создание ролей «по должности» вместо «по задаче». Должность «менеджер по продажам» — одна, но задачи разные: работа с входящими лидами, ведение постоянных клиентов, работа с партнёрской сетью. Каждый сценарий требует своего набора прав.
Рекомендуемый процесс:
- Описать типовые действия каждой группы пользователей за рабочий день
- Определить минимальный набор прав для выполнения каждого действия
- Сгруппировать в роли по набору прав, а не по оргструктуре
Для компании с разделёнными каналами продаж (входящие лиды + ключевые клиенты + партнёры) оптимальная структура ролей:
| Роль | Лиды | Сделки | Контакты | Экспорт |
|---|---|---|---|---|
| Лид-менеджер | A: RW | A: R | C: R | Нет |
| Аккаунт-менеджер | -- | A: RW | A: RW | Нет |
| Партнёрский менеджер | C: RW | C: RW | C: RW | Нет |
| РОП | D: RW | D: RW | D: RW | D |
| Директор | X: RW | X: RW | X: RW | X |
Назначение ролей и множественные роли
Одному пользователю можно назначить несколько ролей — права суммируются (берётся максимальное разрешение из всех ролей). Это удобно для переходных периодов, но создаёт сложность в аудите: непонятно, откуда у пользователя конкретное право.
Лучшая практика: одна роль на пользователя. Если нужно расширить права — создайте новую роль или используйте временное переназначение с логированием.
Назначение роли через API (полезно при автоматизации онбординга):
// Добавить пользователя в роль CRM
CRest::call('crm.role.user.add', [
'roleId' => 5, // ID роли
'userId' => 42, // ID пользователя
]);
Роли для нестандартных сценариев
Внешние агенты и фрилансеры. Битрикс24 позволяет добавлять экстранет-пользователей. Для них создайте отдельную роль с областью видимости A и без экспорта — они видят только свои записи и не могут скачать базу.
Колл-центр на аутсорсе. Операторы должны видеть все входящие лиды, но не должны менять ответственного и не видеть финансовые данные сделок. Настройка: роль с X:R на лиды, запрет поля ASSIGNED_BY_ID на изменение, скрытие поля OPPORTUNITY через права на поля.
Интеграционный пользователь для REST API. Создайте отдельного пользователя-робота с минимальными правами, необходимыми только для интеграции. Не используйте для REST реальные аккаунты сотрудников — при увольнении токен перестанет работать.
Тестирование ролей
После настройки проверяйте роли функцией «Войти как пользователь» (доступна администраторам). Пройдите по типичным сценариям: создать лид, перевести в сделку, найти чужой контакт, попробовать экспортировать список.
Распространённая ошибка: проверяют только то, что роль запрещает, и не проверяют, что разрешено. Убедитесь, что пользователь с новой ролью может выполнить все свои рабочие задачи без обращений к администратору.
Логи изменений ролей пишутся в b_event_log. Регулярный просмотр помогает поймать несанкционированные изменения матрицы прав.