Настройка прав доступа в коробочном Битрикс24 для отделов продаж

Что происходит, если права доступа настроены «как получится»

Коробочный Битрикс24 привлекает бизнес именно тем, что даёт полный контроль: данные хранятся на своём сервере, систему можно дорабатывать под любые процессы, а доступом управляет не вендор, а сама компания. Но эта же свобода превращается в проблему, если права доступа настраивают один раз при внедрении и больше к ним не возвращаются. Через полгода-год отдел продаж вырастает, приходят новые менеджеры, кто-то увольняется, появляются подрядчики с временным доступом — а права остаются прежними. Итог предсказуем: новый сотрудник видит базу клиентов всей компании, уволившийся менеджер продолжает получать уведомления по чужим сделкам, а руководитель отдела не может собрать отчёт, потому что часть сделок скрыта настройками, которые никто не помнит, зачем ставил.

Настройка прав доступа в коробочной версии — это не разовая задача при внедрении, а часть регулярного администрирования CRM, наравне с резервным копированием или обновлением модулей. И если для облачного Битрикс24 многие ограничения задаются мастером настройки в несколько кликов, то в коробке администратор работает с более гибким, но и более сложным механизмом — и должен понимать его логику, а не копировать чужие пресеты.

Из чего состоит система прав в коробочном Битрикс24

В коробочной версии права доступа строятся на нескольких уровнях, которые применяются одновременно, а не по отдельности:

• Уровень модулей. Право заходить в CRM, задачи, диск, телефонию и другие разделы задаётся через группы пользователей в административной панели («Настройки» → «Пользователи» → «Группы пользователей»). Это база — без доступа к модулю CRM все остальные настройки бессмысленны.
• Уровень ролей CRM. Внутри самого CRM-модуля есть отдельная матрица прав: «Менеджер», «Руководитель отдела продаж», «Менеджер по маркетингу» и так далее. Роль определяет, что пользователь может делать с лидами, сделками, контактами, компаниями — просматривать, редактировать, удалять, экспортировать.
• Уровень сущностей. Для каждого типа CRM-сущности (лид, сделка, контакт, компания, счёт) можно задать отдельные права: «Все», «Отдел», «Личные + подчинённых», «Личные». Это ключевой инструмент для отделов продаж — именно здесь ограничивается видимость чужих сделок.
• Уровень полей. В коробочной редакции (в отличие от многих настроек облака) можно скрывать не только карточки целиком, но и отдельные поля внутри карточки — например, скрыть телефон клиента от одной группы менеджеров, оставив видимой остальную информацию.
• Уровень записей через бизнес-процессы. Дополнительно права можно управлять программно — через бизнес-процессы и обработчики событий, которые меняют права на конкретную сделку в зависимости от её стадии, суммы или ответственного.

Ошибка, которую совершают чаще всего: администратор настраивает только первый уровень (доступ к модулю) и не трогает права CRM-сущностей, полагая, что «раз человек в отделе продаж — пусть видит всё, что в CRM». Так база клиентов оказывается полностью открытой для всех менеджеров с первого дня работы.

Права доступа в разрезе иерархии отдела продаж

Для типового отдела продаж имеет смысл выстраивать права по ролям, а не по именам конкретных сотрудников — это упрощает поддержку системы при кадровых изменениях.

Менеджер по продажам. Стандартная настройка — видит и редактирует только те лиды и сделки, где указан ответственным он сам. Права на уровне сущности: «Личные». Это защищает базу от переманивания клиентов при увольнении и снижает риск случайного вмешательства в чужую сделку. Экспорт контактов и компаний для рядового менеджера стоит закрывать полностью или ограничивать без права выгрузки телефонов и email в файл.

Руководитель отдела продаж (РОП). Нужен доступ «Личные + подчинённых» — то есть видимость сделок всех менеджеров, которые ему подчиняются согласно структуре компании в разделе «Компания» → «Структура». Важный нюанс: если оргструктура в Битрикс24 не настроена или настроена некорректно, право «подчинённых» просто не сработает, и РОП увидит только свои личные сделки. Это одна из самых частых причин жалоб «начальник не видит сделки своих менеджеров» — проблема не в правах доступа, а в отсутствии связки «сотрудник — руководитель» в структуре компании.

Коммерческий директор или собственник. Требуется доступ «Все» по всем CRM-сущностям, включая архивные и удалённые записи (право на просмотр корзины отдельно настраивается в правах роли). Здесь же стоит выдавать доступ к сквозной аналитике и BI-конструктору, если он развёрнут.

Менеджер по маркетингу. Обычно нужен доступ на просмотр лидов (для анализа источников) без права редактирования сделок отдела продаж. Отдельно стоит ограничить доступ к телефонии и записям звонков, если это не входит в его задачи.

Подрядчики и временный персонал. Для интеграторов, которые дорабатывают систему, или сезонных сотрудников — создавайте отдельную группу с правами, ограниченными конкретным участком (например, только раздел «Задачи» или тестовая воронка), и обязательно ставьте дату истечения доступа в профиле пользователя, если это предусмотрено вашей редакцией, либо фиксируйте дедлайн отзыва прав в регламенте администратора.

Практический пример: настройка на живом отделе из 12 человек

Разберём кейс, близкий к тому, что встречается у клиентов с коробочным Битрикс24: отдел продаж из 12 человек — 9 менеджеров, 2 РОПа (по направлениям B2B и розница) и коммерческий директор.

Порядок действий, который снимает большинство проблем:

1. В разделе «Компания» → «Структура» создаются два подразделения — «Отдел продаж B2B» и «Отдел продаж — розница», у каждого назначается руководитель (РОП), сотрудники распределяются по подразделениям.
2. Создаются группы пользователей: «Менеджеры продаж», «Руководители отделов продаж», «Коммерческий директор». Для группы менеджеров права на модуль CRM выставляются на основе роли «Менеджер», для РОПов — роль «Руководитель отдела продаж» с автоматической привязкой к правам «Личные + подчинённых».
3. В настройках самой роли CRM для «Менеджера» права на лиды и сделки выставляются как «Личные», на контакты и компании — «Личные», на счета — «Личные», без права удаления карточек (удаление доступно только РОПу и выше — это защищает от случайной потери данных).
4. Для РОПов дополнительно открывается право на просмотр отчётов по своему подразделению и право переназначать ответственного внутри своей команды — это снимает с администратора рутинные перераспределения сделок при отпусках и увольнениях.
5. Отдельно проверяется право экспорта: у рядовых менеджеров оно отключено полностью, у РОПов — ограничено (без выгрузки телефонов), у коммерческого директора — открыто.

После такой настройки конфликт «менеджер видит сделки коллеги» исчезает, а РОП получает предсказуемую картину по своей команде без ручных фильтров каждый раз при формировании отчёта.

Групповые политики вместо ручных настроек по каждому сотруднику

Частая ошибка при настройке коробочной версии — выставлять права каждому сотруднику индивидуально через профиль, а не через группы. Это работает на первых 5–7 пользователях, но при росте отдела превращается в источник хаоса: администратор не может быстро вспомнить, кому и что открыто, а любое изменение регламента требует правки прав вручную у каждого человека.

Правильный подход — все права привязывать к группам пользователей и ролям CRM, а сотрудника только включать в нужную группу. Тогда при найме нового менеджера достаточно добавить его в группу «Менеджеры продаж» — все права применятся автоматически, без риска забыть один из пунктов настройки. При изменении политики (например, решили ограничить экспорт для всех менеджеров) правка вносится один раз на уровне роли, а не 15 раз по числу сотрудников.

Защита базы клиентов: что настроить обязательно

Для бизнеса, где база контактов — это ключевой актив (а для большинства компаний в Казахстане, работающих через CRM, это так), стоит закрыть несколько конкретных дыр, которые чаще всего остаются открытыми по умолчанию:

• Право на экспорт контактов и компаний. Должно быть закрыто для всех, кроме ограниченного круга (РОП, коммерческий директор, администратор). Именно через выгрузку в Excel уходит база при увольнении менеджера.
• Доступ к разделу «Отчёты» и «Аналитика». Не должен автоматически наследоваться от доступа к CRM — иногда стоит открыть карточки сделок, но закрыть агрегированную аналитику по всей компании.
• Права на телефонию и запись звонков. Прослушивание чужих звонков стоит ограничивать ролью — это чувствительная информация о переговорах с клиентами.
• Доступ к API и вебхукам. Отдельная область, которая часто выпадает из внимания при настройке прав пользователей: интеграции и внешние сервисы, подключённые через входящие вебхуки, могут иметь более широкие права, чем сам пользователь в интерфейсе. Список активных вебхуков стоит регулярно проверять в разделе «Настройки» → «Разработчикам».
• Права администратора. Полный доступ должен быть максимум у 1–2 человек. Дать роль администратора «на всякий случай» ещё одному сотруднику — стандартная и опасная практика: это отменяет все остальные ограничения одним аккаунтом.

Как проверить, что права настроены верно

Проверка прав доступа — это не разовая сверка при внедрении, а процедура, которую стоит повторять хотя бы раз в квартал, особенно после изменений в штате. Практический чек-лист для администратора:

1. Зайти под тестовым аккаунтом с ролью «Менеджер» и убедиться, что видны только личные сделки, а чужие — нет ни в списке, ни через прямую ссылку на карточку.
2. Проверить, что уволенные сотрудники деактивированы (а не просто удалены — деактивация сохраняет историю их сделок, но блокирует вход), и их права отозваны.
3. Сверить структуру компании: у каждого менеджера должен быть указан руководитель, иначе право «подчинённых» у РОПа не будет работать корректно.
4. Проверить список активных вебхуков и приложений с доступом к CRM — удалить неиспользуемые.
5. Убедиться, что право на удаление карточек CRM есть только у ограниченного круга ролей.

Если такой аудит ни разу не проводился с момента внедрения коробочного Битрикс24, велика вероятность обнаружить хотя бы одну критичную дыру — чаще всего это открытый экспорт контактов или отсутствие ограничения по «личным» сделкам у рядовых менеджеров.

Результаты каждой такой проверки стоит фиксировать документально — не для отчётности ради самой отчётности, а потому что без письменной фиксации следующий аудит через квартал начинается заново, без понимания, что уже проверялось и что было исправлено в прошлый раз. Достаточно простой таблицы: дата проверки, что проверено, что найдено, что исправлено, кто ответственный. Такой журнал особенно полезен при смене администратора системы — новый сотрудник получает историю решений вместо необходимости реконструировать логику настроек по факту.

Когда стоит привлекать интегратора

Базовая настройка ролей и групп доступна штатному администратору без специальных знаний программирования — интерфейс административной панели рассчитан именно на это. Но есть сценарии, где без опыта работы с коробочной версией легко получить противоречивую настройку:

Например, компания хочет, чтобы менеджер видел свои сделки и сделки коллег из своего же региона, но не видел сделки другого региона внутри того же отдела. Стандартная матрица прав («Личные», «Отдел», «Все») такой сценарий не покрывает — потребуется либо создание виртуальных подразделений под каждый регион, либо настройка прав через бизнес-процессы с проверкой поля «Регион» в карточке сделки. Похожая сложность возникает при интеграции с 1С, внешними складами или несколькими юрлицами внутри одной инсталляции — тогда права нужно согласовывать не только с оргструктурой продаж, но и с финансовым и складским учётом. В таких случаях разумнее заложить время на консультацию с интегратором, который работал с коробочными внедрениями: неправильно настроенные права на этом уровне сложнее переделать постфактум, чем спроектировать сразу — особенно если на момент обнаружения проблемы в системе уже накопились сотни сделок с разными комбинациями ответственных.

Типичные ошибки при настройке прав, которые видит интегратор при аудите

При аудите коробочных инсталляций у клиентов из разных отраслей повторяется один и тот же набор ошибок — их стоит проверить в первую очередь, если система работает уже больше года без пересмотра прав.

Права выставлены на пользователя, а не на роль. Администратор один раз настроил доступ конкретному менеджеру Иванову, а не группе «Менеджеры продаж». Когда приходит новый сотрудник Петров, ему по умолчанию достаются права базовой группы — часто более широкие, чем у Иванова, потому что базовая группа так и осталась не донастроенной с момента внедрения. В результате в одном отделе у разных менеджеров разный набор прав без всякой логики, кроме истории найма.

Деактивированные сотрудники остаются ответственными по активным сделкам. HR увольняет менеджера, администратор деактивирует его учётную запись, но не переназначает его открытые сделки. Формально доступа у бывшего сотрудника уже нет, но сделки «зависают» — не попадают в фильтры активных менеджеров, выпадают из отчётов РОПа, и по факту клиент остаётся без сопровождения, пока кто-то не заметит проблему вручную.

Право «Все» выдано ради удобства тестирования и забыто. На этапе внедрения интегратор временно открывает роли «Менеджер» доступ «Все» по сделкам — чтобы быстрее протестировать воронку и не тратить время на настройку личных прав для тестовых пользователей. После запуска в продакшн эту настройку никто не возвращает к «Личные», и отдел продаж месяцами работает с полностью открытой базой, даже не подозревая об этом.

Смешение прав CRM и прав диска/документов. Часто ограничивают доступ к карточкам сделок, но забывают, что к некоторым сделкам привязаны файлы на общем диске компании (коммерческие предложения, договоры), доступ к которым регулируется отдельными правами модуля «Диск». Менеджер, не имеющий доступа к чужой сделке, иногда всё равно может открыть документ по прямой ссылке, если права диска настроены отдельно и шире, чем права CRM.

Нет регламента на отзыв доступа у подрядчиков. Интегратор, который дорабатывал систему полгода назад, часто так и остаётся в списке пользователей с правами разработчика — доступом к вебхукам, API и иногда к административной панели. Формально работы давно закрыты, но техническая возможность внести изменения в систему у стороннего человека сохраняется.

Каждая из этих ошибок по отдельности не выглядит критичной, но вместе они создают ситуацию, при которой компания не может ответить на простой вопрос «кто и что видит в нашей CRM прямо сейчас» — а это именно то, ради чего изначально выбирали коробочную версию с её обещанием полного контроля над данными.

Частые вопросы

Чем права доступа в коробочной версии отличаются от облачного Битрикс24?
Логика похожая — те же уровни «Личные / Отдел / Все» для CRM-сущностей. Но коробка даёт больше гибкости: можно скрывать отдельные поля карточки, писать собственные обработчики прав через API и глубже настраивать доступ через бизнес-процессы. Это преимущество и одновременно риск — ошибиться в кастомной настройке проще, чем в стандартном мастере облака.

Можно ли настроить, чтобы менеджер видел сделки коллеги временно, например на время отпуска?
Да, для этого не нужно менять базовые права роли — достаточно временно назначить замещающего сотрудника ответственным по конкретным сделкам через групповую операцию в списке CRM, а по возвращении менеджера вернуть ответственность обратно. Права при этом не трогаются, меняется только поле «Ответственный».

Что делать, если руководитель отдела не видит сделки своих менеджеров?
В девяти случаях из десяти причина — не в правах доступа, а в структуре компании: сотрудник не привязан к руководителю в разделе «Структура». Проверьте эту связь в первую очередь, прежде чем менять настройки ролей.

Нужно ли давать администратору коробочного Битрикс24 полный доступ ко всем данным?
Технически администратор системы обычно имеет доступ к базе данных напрямую, независимо от прав в интерфейсе CRM. Поэтому важнее ограничивать не столько доступ администратора, сколько число людей с этой ролью, и вести журнал действий (модуль истории событий доступен в коробочной версии) для контроля.

Как часто нужно пересматривать права доступа?
Минимум раз в квартал, а также сразу при любом кадровом изменении — найме, увольнении, переводе сотрудника между отделами или изменении его роли. Отложенный пересмотр прав — самая частая причина того, что бывшие сотрудники годами остаются в списках ответственных за сделки.