В Битрикс24 нет одной кнопки «дать доступ на всё». Права портала, CRM, задач, проектов и диска живут в разных контурах и считаются по своим правилам. Это частая причина, почему сотрудник вдруг видит лишнее или, наоборот, теряет доступ к нужному.
Почему отдел — это не роль
Отделы задают структуру и иерархию руководителей. Через отдел удобно назначить одну роль сразу группе сотрудников. Но отдел не заменяет права инструмента.
Руководитель подразделения может видеть задачи подчинённых, но при этом не иметь права экспортировать CRM. Менеджер может работать со своими сделками и участвовать в проекте другого отдела, не видя остальные задачи проекта. Такая комбинация нормальна, если она зафиксирована в матрице и проверена.
Шесть контуров прав
| Контур | Что регулирует | Что не регулирует |
|---|---|---|
| Портал и структура | Отделы, сотрудники, приглашения | Конкретные сделки и задачи |
| CRM | Клиенты, сделки, воронки | Задачи, диск, проекты |
| Задачи | Просмотр, изменение, удаление, шаблоны | Файлы и календарь проекта |
| Проекты и группы | Участников, задачи, ленту | CRM и диск вне проекта |
| Диск | Общий и личный диск, папки, файлы | Карточки CRM и задачи |
| Администрирование | Настройки и выдачу прав | Личные чаты и закрытые проекты |
Одинаковое название «Администратор» в разных контурах не означает одинаковые полномочия. Администратор Битрикс24 управляет настройками портала. Администратор CRM настраивает только CRM. Не выдавайте административный уровень портала только ради просмотра сделок отдела.
Как настроить роли CRM
Перед массовой настройкой проверьте путь в своём портале: CRM → Ещё → Настройки → Права доступа к CRM. Ролевая модель доступна не на всех тарифах.
Процесс:
- Составьте список объектов: контакты, компании, лиды, сделки, счета.
- Для каждого объекта отметьте действия: чтение, добавление, изменение, удаление, экспорт, переходы по стадиям.
- Создайте роли по функции, а не по названию отдела: менеджер, руководитель продаж, бухгалтер, контролёр качества.
- Назначьте роли сотрудникам, отделам или группам.
- Проведите тест на карточках каждой воронки.
В CRM несколько наследуемых ролей обычно расширяют доступ, а детализированные права к элементу или стадии имеют приоритет. Поэтому формула «разрешение всегда побеждает запрет» неточна. Проверяйте спорное действие под нужным сотрудником, а не только в таблице настроек.
Проверка через обычного пользователя
Просмотр матрицы из-под администратора не показывает, что увидит менеджер. Проверка должна воспроизводить реальную работу:
- Войдите тестовым менеджером и откройте CRM, задачи, проекты, диск.
- Создайте сделку, задачу, файл и проверьте, кто ещё их видит.
- Войдите руководителем и проверьте данные отдела, подотдела и соседнего подразделения.
- Добавьте специалиста в проект без CRM-роли: он должен видеть задачи проекта, но не получать доступ к CRM.
Результат записывайте как короткий протокол: пользователь, роли, действие, ожидаемый результат, фактический результат, исправление.
Типовые ошибки
- Запрет на стадии не работает из-за смешения наследуемых и детализированных прав.
- Участник проекта видит лишние задачи из-за общих прав задач.
- Файлы проекта недоступны, потому что права проекта их не покрывают.
- После перевода сотрудника доступ остался прежним, потому что роли не пересохранили.
- На Моём диске коллега видит слишком много, потому что доступ выдан на корень, а не на папку.
Для каждого временного исключения укажите владельца решения и дату пересмотра. Иначе временное право станет постоянным.
Top comments (0)