Антон Дегтярёвкак настроить права доступа в битрикс24 без хаоса
В 7 из 10 аудитов нахожу менеджера, который может видеть и редактировать сделки всех остальных отделов — просто потому что при внедрении всем выдали роль «полный доступ», чтобы не разбираться с настройками. Права доступа в Битрикс24 ломаются не потому что система сложная, а потому что их настраивают один раз при запуске и потом никогда не пересматривают под выросшую и изменившуюся компанию. Разбираю по уровням, что проверить и как настроить, чтобы это не превращалось в хаос через год.
почему права доступа — это не одна настройка, а четыре уровня
Владельцы бизнеса часто представляют управление доступом как один переключатель: «этому доступ дать, этому не давать». В Битрикс24 система устроена сложнее — и это не лишняя сложность, а необходимость, потому что доступ к CRM, задачам, диску и базе знаний регулируются раздельно, и внутри самой CRM есть ещё уровни видимости и уровни полей.
Четыре слоя, которые нужно держать в голове отдельно: кто какие сущности CRM видит (свои сделки, сделки отдела, все); какие поля внутри карточки может видеть и редактировать; какие модули вообще доступны (CRM, задачи, диск, база знаний); и отдельно — административные права вроде экспорта базы или изменения настроек системы.
Проблема в том, что при внедрении разбираться со всеми четырьмя слоями долго, и часто идут по простому пути — выдают роль «менеджер» с широким доступом всем подряд, планируя вернуться к тонкой настройке позже. Это «позже» на практике не наступает, пока не случится инцидент или аудит.
уровни видимости: свои, свои плюс подчинённых, отдел, все
В основе системы прав CRM в Битрикс24 — четыре уровня видимости для каждого типа сущности (лиды, сделки, контакты, компании) отдельно. «Свои» — сотрудник видит только те записи, где он назначен ответственным. «Свои плюс подчинённых» — для руководителей, которые должны видеть сделки своей команды, но не соседнего отдела. «Отдел» — видимость в рамках всего подразделения, включая подотделы по структуре компании. «Все» — полный доступ, обычно только у топ-менеджмента и администратора CRM.
Частая ошибка — выдать уровень «все» рядовым менеджерам «для удобства», чтобы они могли подстраховать друг друга или посмотреть похожую сделку коллеги. Формально удобно, по факту — каждый видит переговоры, суммы и условия всех клиентов компании, включая конкурентов внутри одного отдела продаж, если такое соперничество есть.
Правильная логика: менеджер — «свои», руководитель группы — «свои плюс подчинённых», руководитель отдела — «отдел», директор и CRM-администратор — «все». Каждый уровень выше видит меньше лишнего, чем кажется на первый взгляд, и это снижает как утечки, так и банальную путаницу, кто с каким клиентом сейчас работает.
роли по отделам, чтобы не выдать лишнего
Уровень видимости — это ось «сколько записей видно», но есть вторая ось — «какие действия разрешены». Роль в Битрикс24 комбинирует обе: можно дать сотруднику видимость «отдел», но забрать право удалять сделки или менять сумму после согласования.
На практике для типового отдела продаж выделяю минимум три роли, даже если формально все называются «менеджер»: линейный менеджер (создаёт и ведёт сделки в рамках «свои», без права удаления), руководитель группы («свои плюс подчинённых», может менять ответственного внутри команды), и администратор CRM (полный доступ плюс право менять сами настройки прав). Смешивать линейного менеджера и администратора в одной роли — та самая ошибка «всем полный доступ для простоты», которую нахожу чаще всего.
Отдельная категория — бухгалтерия и логистика, если они работают в том же Битрикс24. Им обычно нужен доступ не ко всей сделке, а к конкретным полям — суммы, реквизиты, статус оплаты — без права видеть переписку с клиентом или менять воронку. Для этого нужен третий слой, о котором ниже.
права на поля внутри карточки сделки
Даже при правильно настроенных уровнях видимости остаётся вопрос: видит ли сотрудник вообще все поля карточки, до которой у него есть доступ. Это тонкая настройка, которую часто пропускают, хотя именно она закрывает самые чувствительные утечки.
На одном из аудитов увидел, что менеджер по продажам видел зарплатные поля сотрудников через общий доступ к пользовательским CRM-полям — поле было создано для внутреннего учёта HR, но осталось видимым для всех ролей CRM по умолчанию, потому что при создании поля никто не ограничил его видимость отдельно. Это уже не вопрос удобства, а прямая утечка данных.
Правило простое: любое новое пользовательское поле в карточке сделки или контакта нужно сразу привязывать к нужным ролям, а не оставлять на уровне «видно всем, у кого есть доступ к карточке». Особенно это касается полей с суммами закупки, себестоимостью, персональными данными и внутренними комментариями для руководства — они не должны автоматически наследовать общую видимость карточки.
доступ к задачам, диску и базе знаний отдельно от crm
Права на CRM и права на остальные модули Битрикс24 — разные настройки, и путать их — вторая по частоте ошибка после уровней видимости сделок. Сотрудник может не иметь доступа к CRM вообще, но при этом видеть все задачи компании через общий проект, или наоборот — иметь полный доступ к сделкам, но не видеть базу знаний с регламентами, которые нужны ему для работы.
Для задач и проектов права настраиваются владельцем конкретного проекта отдельно от ролей CRM — это значит, что даже правильно настроенные роли в CRM не гарантируют порядок в задачах, если проекты создавались хаотично с открытым доступом «все участники».
Для диска и базы знаний логика похожая: по умолчанию новая папка или раздел базы знаний часто наследует широкий доступ, если не задать ограничения явно при создании. Смежная тема — организация самой базы знаний, разбирал отдельно в статье про базу знаний в Битрикс24, здесь же важно зафиксировать: права на неё — отдельная настройка, а не производная от прав CRM.
пошагово: настраиваем роль за 15 минут
Сама механика настройки проще, чем кажется. Открываете CRM → Настройки → Права доступа. Слева — список ролей, справа — кому они назначены: конкретным пользователям, отделам из структуры компании или группам. Чтобы завести новую роль, нажмите «Добавить», задайте название («Линейный менеджер», «РОП», «Бухгалтерия») и пройдитесь по матрице: для каждого типа элементов CRM — лиды, сделки, контакты, компании, документы — выбираете, что разрешено из действий: чтение (просмотр карточки), добавление, изменение (редактирование), удаление, экспорт, импорт. И для каждого действия — свой уровень видимости: свои, свои и подчинённых, все открытые, все. Для сделок права можно указать ещё и в разрезе стадий воронки: например, менеджер двигает сделку до стадии согласования, а дальше редактирование доступно только руководителю.
Дальше назначение: нажмите «Добавить право доступа», выберите отдел или группу пользователей — и роль применится ко всем, кто туда входит. Назначать роль на отдел, а не на людей поимённо — принципиально: новый сотрудник отдела продаж получит правильные права автоматически при добавлении в структуру, а не «полный доступ по умолчанию, потом разберёмся». После изменений не забудьте сохранить — настройки применяются сразу, перелогин не нужен.
На типовую компанию из трёх отделов у меня уходит минут 15 на сами клики. Ещё раз: основное время — не интерфейс, а согласование логики. Матрицу «роль × действия» я сначала рисую в таблице и утверждаю с руководителями, и только потом переношу в портал.
права за пределами crm: телефония, маркетинг, отчёты
Отдельный пласт, который пропускают в 9 из 10 порталов на моих аудитах, — права в смежных инструментах. Телефония: право слушать записи чужих звонков и смотреть детализацию настраивается отдельно в настройках телефонии — и по умолчанию записи разговоров часто доступны шире, чем сделки, к которым эти звонки привязаны. Получается парадокс: сделку конкурента менеджер не видит, а его переговоры с клиентом — слушает.
CRM-маркетинг — второй чувствительный раздел: право на массовые рассылки означает доступ ко всей базе контактов, фактически это тот же экспорт, только через письмо. Даю его только маркетологу и администратору. Аналитика и отчёты — третий: сводные отчёты по продажам показывают суммы и конверсию всех отделов, и если доступ к отчётам открыт всем, уровни видимости сделок теряют смысл — цифры всё равно видны через дашборд.
Правило: после настройки ролей CRM пройдитесь по каждому инструменту, который включён на портале, — телефония, открытые линии, маркетинг, аналитика, диск — и задайте себе один вопрос: «кто видит эти данные в обход прав CRM?» Это же касается и сквозной аналитики, где собираются данные сразу всех отделов.
облако и коробка — разные возможности разграничения
В облачной версии Битрикс24 набор инструментов разграничения фиксированный: роли CRM, права на инструменты, настройки проектов и диска. Для большинства компаний до 50 человек этого достаточно. Важный нюанс тарифов: гибкая настройка прав доступа в CRM доступна не на всех тарифах облака — на младших план продаж и роли урезаны, это стоит проверить до покупки, а не после.
Коробочная версия — корпоративный портал на своём сервере — даёт дополнительный контур: группы безопасности на уровне модулей, разграничение вплоть до отдельных файлов и папок, интеграция с доменной авторизацией (Active Directory), и главное — возможность дорабатывать логику прав кодом под нестандартные требования: доступ по регионам, по юрлицам, по грифам конфиденциальности. Подробно о выборе редакции писал в сравнении облака и коробки.
Практический ориентир: если у вас требования уровня «служба безопасности согласовывает матрицу доступа» — это почти всегда коробка. Если задача — «менеджеры не видят чужих клиентов» — облака хватает с запасом.
типовые конфликты прав и как их ловить
Самый коварный механизм, о котором не знает большинство администраторов: если сотрудник попадает под несколько ролей одновременно — например, состоит в двух отделах или добавлен и в отдел, и в группу с другой ролью, — действует наиболее широкое из назначенных прав. Урезали роль отдела, а у человека осталась старая персональная роль с «видеть все» — и формально правильная настройка не работает. Поэтому при ревизии смотрю не только роли, но и все назначения на конкретного пользователя.
Второй типовой конфликт — участники и наблюдатели в карточке: сотрудник с видимостью «свои» всё равно видит чужую сделку, если его добавили туда наблюдателем. Это штатное поведение, но о нём нужно помнить: массовое добавление «всех причастных» в наблюдатели фактически обнуляет разграничение. Третий — автоматизация: роботы и бизнес-процессы выполняют действия с правами, заданными в их настройках, и могут менять данные, к которым у инициатора доступа нет — при аудите проверяю и это, особенно если бизнес-процессы настраивали давно и другие люди.
Ловятся такие конфликты одним способом — тестовым входом под учёткой сотрудника, а не чтением матрицы ролей. Матрица говорит, как должно быть, живой портал — как есть на самом деле. Расхождения между ними я нахожу практически на каждом сопровождении.
как проверить текущие права за 10 минут
Быстрая проверка, которую можно провести самостоятельно, без привлечения специалиста, — зайти под тестовым менеджерским аккаунтом (или попросить рядового сотрудника показать экран) и посмотреть список сделок: видно ли там что-то за пределами «своих» без явной должностной необходимости.
Второй шаг — открыть раздел CRM → Настройки → Права доступа и пройтись по списку ролей: сколько ролей реально используется, а сколько создано «на всякий случай» и не назначено никому — лишние роли усложняют аудит и часто содержат забытые широкие права. Третий шаг — проверить, кто имеет право на массовый экспорт контактов и сделок в файл: это единственная функция, которая может вынести всю базу клиентов за пределы компании одним кликом, и доступ к ней должен быть у минимального числа людей.
Если на этих трёх шагах уже находится хотя бы одно расхождение с ожиданием — это сигнал, что права не пересматривались давно, и стоит провести полную ревизию, а не точечную правку одного аккаунта.
что делать при росте компании — пересмотр прав
Частая ошибка растущих компаний: права настроили на 8 менеджеров при запуске, а через год их 25 — и никто не разбил структуру на отделы, все так и остались в одной общей видимости. Права, которые были адекватны для маленькой команды, где все всех знают, для 25 человек превращаются в проблему конфиденциальности и просто в шум — сложно найти нужную сделку среди сотен чужих.
Пересмотр прав логично привязывать не к календарю, а к событиям: открытие нового отдела или направления, рост штата на 20% и больше, смена руководителя отдела, инцидент с утечкой данных или жалоба сотрудника на то, что видит лишнее. В остальное время достаточно точечной проверки раз в полгода — той самой, что описана в предыдущем разделе.
Если компания уже выросла и права давно не пересматривались, разумно совместить эту работу с полным аудитом Битрикс24 — права там лишь одна из зон, но обычно самая чувствительная по последствиям. Я подробно описывал остальные зоны в чек-листе на 40 пунктов для аудита Битрикс24.