Налаштування прав доступу в CRM Бітрікс24
Коли в CRM працюють 30+ людей з різних відділів, відсутність нормально налаштованих прав доступу перетворюється на проблему безпеки та операційний хаос. Менеджери бачать чужі угоди й випадково їх редагують, керівники не можуть швидко перевірити воронку конкуруючого відділу, а аналітик із правами адміністратора видаляє потрібні записи.
Система прав у CRM Бітрікс24 будується на ролях із матрицею дозволів за сутностями та операціями. Правильна конфігурація вимагає розуміння кількох рівнів: ролі CRM, права на елементи, обмеження за полями та правила видимості.
Архітектура прав доступу CRM
Права в CRM незалежні від загальних прав Бітрікс24 (за винятком глобальних адміністраторів). Ієрархія:
- Ролі CRM — набір дозволів за типом операцій (перегляд, створення, редагування, видалення, експорт)
- Рівні доступу до елементів — свої / свого підрозділу / всі
- Права на поля — приховування або блокування конкретних полів картки
- Права на воронки та стадії — обмеження роботи з конкретними pipeline
Налаштування: CRM → Налаштування → Права доступу → Ролі.
Налаштування ролей
Мінімальний набір ролей для типової компанії:
| Роль | Ліди | Контакти | Угоди | Компанії | Звіти |
|---|---|---|---|---|---|
| Менеджер | Свої: R/W | Свої + відділ: R | Свої: R/W | Свої: R/W | Ні |
| Старший менеджер | Відділ: R/W | Відділ: R/W | Відділ: R/W | Відділ: R/W | Відділ |
| РВП | Всі: R/W | Всі: R/W | Всі: R/W | Всі: R/W | Всі |
| Аналітик | Ні | Всі: R | Всі: R | Всі: R | Всі |
Критичний нюанс: право «видалення» слід надавати лише РВП та вище. Видалені записи без кошика не відновлюються (якщо кошик вимкнено в налаштуваннях).
Обмеження видимості за підрозділами
Рівень «свого підрозділу» працює через структуру компанії в Бітрікс24. Якщо структуру не заповнено або менеджер не прив'язаний до підрозділу — він побачить усі записи, навіть із обмеженою роллю. Це часта помилка при первинному налаштуванні.
Перевірити структуру: Компанія → Структура компанії. Кожен користувач має бути прив'язаний до конкретного відділу, а не «висіти» в корені.
Для мультирегіональних компаній з кількома філіями використовуйте групи підрозділів через API:
// Отримати підрозділ користувача
$department = CIBlockSection::GetList(
[],
['UF_HEAD' => $userId],
false,
['ID', 'NAME']
);
Права на поля картки
Приховування полів налаштовується окремо від прав на сутності: CRM → Налаштування → Права доступу → Права на поля. Можна приховати поле повністю або зробити його доступним лише для читання для конкретної ролі.
Типовий сценарій: поле «Маржа угоди» або «Собівартість» бачать лише РВП і фінансовий директор, менеджери бачать лише підсумкову суму.
Обмеження працює на рівні інтерфейсу. Через REST API поле залишається доступним, якщо у користувача є токен із потрібними правами. Для серйозного захисту фінансових даних потрібно додатково обмежувати права на REST-застосунки.
Права на воронки та смарт-процеси
Починаючи з Бітрікс24 версії 22.x з'явилися права на конкретні воронки угод. Менеджер роздрібних продажів не повинен бачити воронку корпоративних клієнтів — це налаштовується в CRM → Угоди → Налаштування воронки → Права доступу до воронки.
Смарт-процеси (SPA) мають власну матрицю прав, незалежну від стандартних сутностей. Налаштування через CRM → Смарт-процеси → [вибрати] → Права доступу.
Аудит змін прав
Зміни в правах доступу логуються в таблиці b_event_log із типом подій CRM_*. Для регулярного аудиту зручно вивантажувати лог через REST:
CRest::call('log.get', [
'filter' => ['TYPE' => 'CRM_PERMISSIONS_CHANGED'],
'order' => ['DATE_CREATE' => 'DESC'],
'limit' => 50,
]);
Раз на квартал переглядайте матрицю прав — особливо після звільнень і переміщень співробітників. Звільнені користувачі з активними ліцензіями залишаються загрозою до деактивації облікового запису.