Налаштування ролей у 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. Регулярний перегляд допомагає виявити несанкціоновані зміни матриці прав.