Короткий ответ
Права доступа к CRM в Битрикс24 настраиваются через ролевую модель: CRM → Ещё → Настройки → Права доступа. Вы создаёте роль, назначаете её сотруднику, отделу или группе, а внутри роли задаёте для каждого объекта CRM — лиды, сделки, контакты, счета — что с ним можно делать и в каком объёме.
Механику подробно описывает документация вендора, и пересказывать её целиком смысла нет. Полезнее другое: разобрать, где эта конструкция разъезжается с реальностью. По нашему опыту аудитов права почти никогда не ломаются в момент настройки — они ломаются потом, тихо, и обнаруживаются, когда уже стоят денег.
Как устроена ролевая модель прав в Битрикс24
Роль — это набор правил «объект + действие + область». Действия стандартные: чтение, добавление, изменение, удаление, плюс экспорт, импорт и настройка карточки.
Интереснее область доступа. Для каждого действия выбирается один из уровней:
| Уровень | Что видит сотрудник |
|---|---|
| Нет доступа | Действие запрещено |
| Свои | Только элементы, где он ответственный |
| Свои + своего отдела | Плюс элементы коллег по отделу |
| Свои + отдела + подотделов | Плюс подчинённые подразделения |
| Все открытые | Плюс элементы с пометкой «Доступен для всех» |
| Все | Вся база |
Типовая схема для отдела продаж выглядит так:
| Роль | Свои сделки | Сделки отдела | Все сделки |
|---|---|---|---|
| Менеджер | читать, изменять | читать | — |
| РОП | читать, изменять | читать, изменять | читать |
| Собственник | читать, изменять | читать, изменять | читать, изменять |
Настраивается это за полчаса. Дальше начинается то, ради чего статья.
Что ломается в правах доступа на практике
1. Несколько ролей — применяется максимум, а не пересечение
Самая частая ошибка, и самая контринтуитивная. Если на сотруднике висит две роли, система даёт наиболее широкий уровень доступа из обеих. Не строгий, а мягкий.
На практике это выглядит так: менеджеру когда-то временно выдали роль с расширенным доступом — подменял РОПа в отпуске. Отпуск закончился, роль осталась. Дальше руководитель настраивает роль «Менеджер» как надо, проверяет — и не понимает, почему человек по-прежнему видит всю базу.
Что делать: прежде чем править настройки роли, откройте список ролей, назначенных на конкретного человека. Чинить надо там.
2. Оргструктура портала не совпадает с реальным подчинением
Уровни «Свои + своего отдела» и «+ подотделов» опираются на дерево компании в портале. Оно заполняется один раз при внедрении и почти никогда не обновляется.
Люди переходят между отделами, появляются новые направления, кто-то начинает подчиняться напрямую собственнику. В портале при этом всё как было два года назад. Права формально настроены верно — а фактически сотрудник видит отдел, к которому давно не имеет отношения, и не видит тот, в котором работает.
Что делать: оргструктура — часть системы прав, а не справочник для красоты. Пересматривать при каждом кадровом изменении.
3. Права на стадиях перекрывают общие
Для лидов, сделок и смарт-процессов права задаются в том числе по отдельным стадиям воронки. По умолчанию стадия наследует права родителя, но на конкретной стадии можно задать своё значение — и оно перекроет общее правило.
Это удобно и это же источник протечек: общая настройка выглядит корректно, руководитель проверяет её и успокаивается, а доступ утекает на уровне одной стадии, куда никто не заглядывал.
Что делать: проверять не только общие права роли, но и переопределения на стадиях. Особенно на тех, куда сделки попадают редко.
4. Уволенные сотрудники остаются ответственными
Это не ошибка настройки прав в узком смысле — это отсутствие процесса при увольнении. Но обходится дороже всего остального вместе взятого.
В аудите одной B2B-компании в строительном сегменте мы нашли 93 сделки на 529,5 млн ₽, которые числились за 116 уволенными сотрудниками. Не проигранные и не потерянные — просто висящие на людях, которых нет в компании. В отчётах они выглядят живым пайплайном: сумма есть, стадия есть, дата закрытия есть. Никто по ним не звонит.
Механика простая. Учётную запись уволенного увольняют в портале не сразу или не увольняют вовсе. Его сделки остаются на нём. Уровень «Свои» означает, что их не видит больше никто, а раз не видит — не ведёт.
Что делать: увольнение сотрудника в портале должно включать переназначение его сделок и лидов. Это регламент, а не настройка. Проверяется за десять минут: отфильтруйте сделки по ответственным и сверьте список с актуальным штатом.
Полный разбор того аудита — в отдельной статье.
5. Лиды без ответственного
Зеркальная проблема. Лид приходит из канала, у которого не настроено распределение, и падает в базу без ответственного. При уровне доступа «Свои» его не видит вообще никто: он не «свой» ни для кого.
Формально портал работает, лид зафиксирован, конверсия падает без видимой причины.
Что делать: проверить, что у каждого источника лидов задано правило распределения, и завести регулярную проверку на лиды без ответственного. В нашем аудите это одна из двенадцати зон, которые мы смотрим отдельно.
6. Права CRM — не единственные права в портале
Отдельная путаница, из-за которой настройка выглядит сделанной, а доступ открыт.
Роли CRM управляют доступом к сделкам, лидам, контактам и счетам. Но в портале есть и другие права: на Диск, Задачи, Календарь, Чаты, отчёты. Они настраиваются в своих разделах и с ролями CRM не связаны никак. Ограничив менеджера в CRM, вы не ограничили его в общем Диске, где лежит выгрузка клиентской базы за прошлый год.
И главное: администратор портала видит всё независимо от ролей CRM. Роль на него просто не действует. Если в компании пять администраторов, потому что «так было удобнее настраивать», то пять человек имеют полный доступ ко всему, какие бы роли им ни назначили.
Но хуже другое, и это уже не про безопасность. Когда администраторов много, за настройки не отвечает никто.
Воронка изменилась, робот перестал срабатывать, обязательное поле вдруг стало необязательным — и выяснить, кто и когда это сделал, невозможно. Каждый из пяти администраторов честно говорит, что не трогал, и, скорее всего, не врёт: настройку менял кто-то полгода назад, походя, решая свою задачу. История изменений в портале ведётся не по всем настройкам, восстановить картину не из чего.
В итоге поломка обсуждается не как «вот причина, вот исправление», а как «кто-то что-то сделал». Никто не виноват, а значит, и не чинит: у проблемы нет владельца, как не было владельца у настройки.
Это ровно та ситуация, когда техническая мелочь превращается в управленческую. Право администратора — это не «удобнее работать», это ответственность за то, как устроена система.
Что делать: проверить список администраторов портала — это отдельный список, не роли CRM. Оставить тех, кому это действительно нужно: обычно одного-двух, и это должны быть люди, готовые отвечать за настройки, а не те, кому когда-то было неудобно просить. Остальным выдать роль с нужным уровнем — в девяти случаях из десяти админские права им были нужны для одной конкретной операции, а остались навсегда.
7. Право на экспорт выдают не думая
В настройках роли экспорт стоит в одном ряду с чтением и изменением, и его отмечают заодно. Между тем это принципиально другое право: чтение позволяет посмотреть сделку, экспорт — выгрузить всю доступную базу в файл и унести.
Для менеджера, который видит только свои сделки, риск невелик. Для роли с доступом «Все» экспорт означает, что клиентская база компании выгружается в два клика любым, у кого эта роль есть.
Что делать: экспорт выдавать отдельным решением, а не в комплекте. Проверить, у каких ролей он сейчас включён и совпадает ли это с вашими ожиданиями.
Как проверить настройку прав за десять минут
- Возьмите трёх сотрудников с разными ролями. Посмотрите на портал их глазами: сколько сделок каждый видит в общем списке.
- Если кто-то видит больше положенного — откройте список ролей, назначенных на него, а не настройки роли.
- Сверьте оргструктуру портала с реальным подчинением на сегодня.
- Отфильтруйте сделки по ответственным и сверьте список с актуальным штатом. Уволенные не должны встречаться.
- Проверьте лиды без ответственного за последний квартал.
- Загляните в переопределения прав на стадиях воронки.
- Откройте список администраторов портала — это отдельный список, не роли CRM.
- Посмотрите, у каких ролей включён экспорт.
Если на любом из шагов нашлось расхождение — оно там не первый месяц.
Когда настройку прав проще отдать подрядчику
Разовая настройка прав — задача на полдня, и её нет смысла кому-то поручать: разберётесь по документации быстрее, чем найдёте подрядчика.
Обращаться имеет смысл в двух случаях. Первый — когда портал живёт несколько лет, через него прошли разные подрядчики и поколения сотрудников, и вы не знаете, где ещё разъехались настройки, кроме прав. Второй — когда нужно не «настроить права», а перестроить логику: разграничить доступ между направлениями, закрыть филиалы друг от друга, развести дилерскую сеть.
В первом случае разумнее начать с бесплатного аудита: агент проходит двенадцать зон, включая права и брошенные сделки, и показывает, где именно теряется. Отчёт ваш в любом случае — чините сами или с любым подрядчиком.
На каких тарифах доступна настройка прав
Ролевая модель прав в CRM — функция коммерческих тарифов Битрикс24. На бесплатном её нет, и обойти это нельзя: ограничение вендора.
Если нужна помощь с настройкой портала — смотрите внедрение и настройка Битрикс24.