Права доступа в Битрикс24: как собрать роли от структуры компании

Где живут права и из чего они состоят

Настройка лежит в разделе CRM → Ещё → Настройки → Права доступа к CRM. Менять её может администратор портала или сотрудник с правом «Разрешить изменять настройки» в самой CRM. Про второй вариант стоит помнить: это право даёт полный доступ и к самим правам, поэтому раздавать его руководителям отделов «чтобы сами поправили воронку» я не советую.

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

Внутри роли права задаются по двум осям. Первая — элемент: контакты, компании, лиды, сделки в каждой воронке отдельно, предложения, счета, план продаж и ещё несколько разделов. Вторая — действие: чтение, добавление, изменение, удаление, экспорт, импорт, настройка роботов, просмотр суммы на стадиях канбана, перемещение на стадию. Для каждой пары выбирается уровень:

• «Свои» — элементы, где сотрудник ответственный;
• «Своего отдела» и «Подотделов отдела» — элементы коллег по отделу и нижестоящих отделов;
• «Своих команд» и «Своих команд и команд в подчинении» — то же для команд;
• «Все открытые» — элементы с отметкой «Доступен для всех»;
• «Всех сотрудников» — всё подряд.

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

Роли назначаю отделам, а не людям

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

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

Справка Битрикс24 советует настраивать права сверху вниз: сначала отделы, потом подотделы, и не пользоваться ролью «Все сотрудники отдела с подотделами», а заводить роли для каждого подразделения отдельно. С этим я согласен по опыту. Роль на весь отдел с подотделами удобна ровно до первого исключения, после которого её начинают дублировать.

Что происходит, когда ролей у сотрудника несколько

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

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

Проверить итог можно прямо в настройке прав: в поле рядом со строкой поиска выбирается сотрудник, и в окне видны все назначенные ему роли. Я делаю так после каждой правки, это дешевле, чем разбирать жалобу «пропали сделки» через неделю.

Права на стадии: руководитель видит всё, менеджер работает со своим

Для лидов, сделок и смарт-процессов права можно задать на конкретные стадии. На этом строится схема, которая хорошо работает в отделах с общим входящим потоком.

На первой стадии сделки, условно «Новая заявка», у роли менеджера стоит чтение всех элементов. Менеджеры видят общую очередь. Дальше заявку забирает конкретный человек: робот «Изменить ответственного» раздаёт сделки по очереди или случайно, может пропускать сотрудников в отпуске и тех, у кого закончился рабочий день. На следующих стадиях у менеджера остаётся уровень «Свои», и чужие сделки из его канбана пропадают.

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

Справка предупреждает про нагрузку: когда пользователей, ролей и детализированных прав много, CRM работает медленнее. Если право на стадии повторяет общее правило, я оставляю наследование и не прописываю его вручную. На больших порталах с десятком воронок это заметно.

Уволенный сотрудник и его сделки

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

Штатный порядок описан в справке. В списке сделок фильтр «Ответственный» показывает вкладку «Уволенные», там выбираются карточки и через «Выбрать действие» меняется ответственный, в том числе для всех элементов на всех страницах. То же для лидов, контактов, компаний и предложений. Менять ответственного нужно и в закрытых сделках, иначе повторное обращение клиента снова уйдёт уволенному.

Дальше начинаются нюансы. Дела, созданные в сделках, переносятся отдельно, через раздел «Мои дела». Счета меняются только в карточке счёта. Если сотрудник уже уволен, для переноса дел и счетов его приходится временно вернуть на портал, а потом уволить снова.

Руками по этой последовательности проходят один раз. Во второй раз кто-то забывает про дела, в третий про закрытые сделки. Поэтому на порталах, где текучка в отделе продаж заметная, я пишу небольшой обработчик на REST API: за один запуск он находит все сделки, контакты, компании, дела и счета уволенного сотрудника, включая закрытые, и передаёт их руководителю группы или следующему менеджеру по очереди. Обработчик запускается раз в сутки и ищет отключённых сотрудников, за которыми ещё числятся элементы. Отдел кадров отключает человека, к утру его клиенты уже у коллег.

Структура изменилась, права не сработали

Второй частый сюжет. Руководитель отдела сменился или менеджер перешёл в другую группу. Структуру компании поправили, роли назначены отделам, всё по схеме. Новый руководитель не видит сделки подчинённых.

Причина описана в справке прямо: новые права применяются к элементам, созданным после изменения структуры. Старые элементы нужно пересохранить, например выбрать для них того же ответственного. Массовое действие это позволяет, но о нём надо знать. Я добавляю пересохранение в тот же ночной обработчик: он сравнивает отделы сотрудников со вчерашним снимком и пересохраняет элементы тех, кого переместили, без участия администратора.

Разные воронки для разных отделов

Когда в CRM несколько воронок, права на сделки задаются для каждой отдельно. Сотрудник видит только те воронки, где у него есть хотя бы право на чтение сделок. Это удобно для разделения: продажи работают в своей воронке, производство или доставка в своей, и каждый отдел видит только свои карточки.

На стыке отделов сделку передают через туннель продаж: на стадии одной воронки сделка копируется или перемещается в другую. Здесь права стоит продумать заранее. Если сделка перемещается, менеджер продаж после передачи её больше не видит и не может ответить клиенту, который спрашивает о сроках. Если копируется, в двух воронках живут две сделки и суммы надо разводить в отчётах. Я обычно выбираю копирование и даю продажам чтение на воронку производства: менеджер видит статус заказа, но не может его поменять.

Как права выглядят на портале, который достался от прежнего подрядчика

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

Сначала кто-то из руководителей попросил поправить воронку сам, и ему выдали «Разрешить изменять настройки». Потом ещё двоим. Через год стадии и поля меняют пять человек, и уже не восстановить, откуда в сделке взялось поле «Источник 2».

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

Отдельно смотрю на экспорт. Для ежедневной работы менеджеру выгрузка базы в файл не нужна, отчёты строит руководитель. Это право я оставляю руководителям и снимаю с линейной роли.

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

Если портал достался вам в таком состоянии и непонятно, с чего начинать, этот разбор входит в аудит портала Битрикс24. Про то, что забрать у прежнего подрядчика до разрыва, я писал отдельно: как сменить интегратора Битрикс24.