Проєктування ролей та прав доступу в CRM Бітрікс24
Налаштування ролей у CRM Бітрікс24 — одна з частих точок відмови в продажах. Ми бачили це на сотнях проєктів: неправильні права призводять або до витоку даних, або до блокування співробітників. Нещодавній кейс: меблева фабрика з областю видимості D — менеджери бачили угоди колег, зливали клієнтів, втратили 2 великих контракти за місяць. Аудит прав зайняв 4 години, виправлення — ще день. Результат: витік зупинено, кожен менеджер бачить лише свої ліди та угоди, РОП — підрозділ. Гарантуємо, що після нашого налаштування кожен користувач отримає рівно ті права, які потрібні для його завдань, і жодним більше. Оцінимо ваш проєкт за 1 день, зв'яжіться — отримайте консультацію.
Які права можна налаштовувати в CRM?
Кожна роль у Бітрікс24 визначає права за двома вимірами: тип операції та область видимості. Типи операцій: читання, додавання, зміна, видалення, експорт, імпорт, перегляд звітів. Області видимості:
-
--— немає доступу -
A— лише свої записи -
B— свої + підлеглих (працює лише при правильній ієрархії) -
C— свій підрозділ -
D— підрозділ + дочірні -
X— всі записи
Без коректної ієрархії керівник–підлеглий область B поводиться як A — це часта причина, чому 80% конфліктів прав залишаються непоміченими.
Чому ролі за посадою — це помилка?
Проєктування ролей «за посадою» замість «за завданням» призводить до надлишкових або недостатніх прав. Наприклад, «менеджер з продажу» — одна посада, але завдання різні: робота з вхідними лідами, ведення ключових клієнтів, партнерська мережа. Для кожного сценарію потрібен свій набір прав.
Рекомендований процес (перевірено на 50+ проєктах):
- Опишіть типові дії кожної групи користувачів за робочий день.
- Визначте мінімальний набір прав для кожної дії.
- Згрупуйте в ролі за набором прав, а не за оргструктурою.
Для компанії з розділеними каналами продажів (вхідні ліди + ключові клієнти + партнери) оптимальна структура ролей:
| Роль | Ліди | Угоди | Контакти | Експорт |
|---|---|---|---|---|
| Лід-менеджер | 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 |
Порівняння ролей за ефективністю: роль, спроєктована під завдання, скорочує кількість запитів до адміністратора в 2–3 рази порівняно з роллю «за посадою». Це дає економію часу до 10 годин на місяць на одного співробітника.
Як призначити декілька ролей користувачеві?
Одному користувачеві можна призначити декілька ролей — права підсумовуються (береться максимальний дозвіл). Це зручно для перехідних періодів, але створює складність в аудиті: незрозуміло, звідки у користувача конкретне право.
Найкраща практика: одна роль на користувача. Якщо потрібно розширити права — створіть нову роль або використовуйте тимчасове переназначення з логуванням.
Призначення ролі через API (корисно при автоматизації онбордингу):
// Додати користувача в роль CRM CRest::call('crm.role.user.add', [ 'roleId' => 5, // ID ролі 'userId' => 42, // ID користувача ]); Що входить у налаштування ролей
Ми пропонуємо налаштування ролей під ключ. У послугу входить:
- Аналіз поточних прав і бізнес-процесів
- Проєктування матриці ролей (від 2 до 5 робочих днів)
- Створення ролей і призначення користувачам
- Тестування через «Увійти як користувач»
- Передача документації з прав
- Підтримка протягом 2 тижнів після здачі
Досвід понад 10 років і сертифіковані спеціалісти гарантують, що ви не зіткнетеся з типовими помилками. Замовте налаштування — і ваша команда продажів отримає правильний доступ без простоїв.
Ролі для нестандартних сценаріїв
Зовнішні агенти та фрилансери. Бітрікс24 дозволяє додавати екстранет-користувачів. Створіть окрему роль з областю видимості A та без експорту — вони бачать лише свої записи і не можуть завантажити базу.
Кол-центр на аутсорсі. Оператори повинні бачити всі вхідні ліди, але не змінювати відповідального та не бачити фінансові дані. Налаштування: роль з X:R на ліди, заборона поля ASSIGNED_BY_ID на зміну, приховування поля OPPORTUNITY через права на поля.
Інтеграційний користувач для REST API. Створіть окремого користувача-робота з мінімальними правами, необхідними лише для інтеграції. Не використовуйте реальні акаунти співробітників — при звільненні токен перестане працювати.
Як тестувати ролі після налаштування?
Після налаштування перевіряйте ролі функцією «Увійти як користувач» (доступна адміністраторам). Пройдіть за типовими сценаріями: створити лід, перевести в угоду, знайти чужий контакт, спробувати експортувати список. Переконайтеся, що користувач може виконати всі робочі завдання без звернень до адміністратора.
Чекліст тестування ролей
- Створити лід і угоду від імені користувача
- Спробувати змінити відповідального по угоді
- Відкрити чужий контакт (має бути заборонено, якщо область не X/D)
- Експортувати список контактів (якщо заборонено — помилка)
- Перевірити доступ до звітів CRM
Логи змін ролей записуються в b_event_log. Регулярний перегляд допомагає виявити несанкціоновані зміни матриці прав. Більш детально про права доступу — у документації Бітрікс24.
Отримайте консультацію з налаштування ролей — ми оцінимо ваш проєкт і запропонуємо оптимальну матрицю прав.