Роли и права доступа в CRM: что разрешить менеджеру, исполнителю и руководителю
Как составить матрицу доступа для своей CRM: видимость клиентов, изменение заказов, экспорт, временные права и проверка ограничений перед запуском.
Права стоит описывать через конкретные действия и наборы данных. Сотруднику может быть разрешено вести свои заказы, но запрещено выгружать всю клиентскую базу или менять подтверждённые оплаты.
Начните с действий, которые выполняет команда
Названия ролей сами по себе мало объясняют разработчику. Менеджер в одной компании только принимает обращения, а в другой согласует скидки, меняет адрес доставки и оформляет возвраты. Поэтому до проектирования CRM полезно разобрать обычный рабочий день каждого участника.
Для каждого действия укажите объект, условие и границу. Например: оператор меняет состав своего заказа до передачи на сборку; после передачи отправляет запрос старшему смены. Так право связано с процессом, а не просто с наличием кнопки на экране.
Отдельно перечислите данные, которые нужны для выполнения работы. Исполнителю может требоваться комментарий к изделию и срок готовности, но не история покупок клиента. Это влияет и на доступ, и на состав его рабочего экрана.
Соберите небольшую матрицу доступа
Удобно разложить разрешения по таблице и обсудить спорные ячейки с владельцами процессов. Не объединяйте просмотр, изменение и выгрузку в одно общее право работать с клиентами. Массовые операции тоже стоит описать отдельно.
Ниже условный пример для команды, которая принимает и исполняет заказы. Это отправная точка для обсуждения, а не универсальная схема для любого бизнеса.
| Действие | Менеджер | Исполнитель | Руководитель |
|---|---|---|---|
| Просмотреть заказ | Свои и назначенные | Назначенные задания | Заказы своего подразделения |
| Изменить обещанный срок | До передачи в работу | Предложить новый срок | Подтвердить перенос |
| Выгрузить клиентов | Нет | Нет | По отдельному разрешению |
| Изменить подтверждённую оплату | Нет | Нет | Запросить корректировку у ответственного |
Продумайте замены сотрудников и особые случаи
Клиент не должен оставаться без ответа из-за отпуска менеджера. Вместо постоянного доступа ко всем заказам можно предусмотреть временную передачу выбранных клиентов с датой окончания. В истории должно быть понятно, кто работал с заказом во время замены.
Обсудите совместные проекты, филиалы и смену ответственного. Что происходит со старыми комментариями после передачи? Видит ли предыдущий менеджер дальнейшие оплаты? Кто разбирает обращение, если сотрудник уже уволен? Эти ситуации лучше решить до появления первой спорной карточки.
- Кто выдаёт и отзывает временные разрешения.
- Какие действия требуют подтверждения второго сотрудника.
- Что сохраняется в истории при исправлении суммы, статуса или срока.
- Кому переходят незавершённые задачи после отключения учётной записи.
Проверяйте ограничения за пределами интерфейса
Скрытая кнопка помогает организовать экран, но не заменяет проверку доступа на сервере. OWASP рекомендует проверять разрешения при каждом запросе и выдавать только необходимые для работы права. Это относится и к выгрузкам, вложениям, поиску и прямым ссылкам на карточки.
В приёмке полезны парные сценарии: менеджер открывает свой заказ и получает отказ при обращении к чужому; исполнитель видит файл задания, но не финансовое вложение. После отзыва доступа стоит проверить уже открытые вкладки и действующие сеансы.
Включите модель доступа в разработку CRM
Для оценки кастомной CRM достаточно начать с перечня ролей, нескольких реальных сценариев и списка чувствительных операций. PXL Perfect помогает превратить их в рабочие экраны и проверяемые правила доступа. Состав разрешений согласуется под вашу команду.
При добавлении нового модуля матрицу нужно дополнять. Иначе у системы появятся отчёты или массовые действия, для которых никто не определил владельца и допустимый круг пользователей.