Доступ и роли
Доступ определяет, кто и что видит и может делать в портале. Для владельца и администратора это не набор галочек, а модель ответственности: сотрудник работает со своими задачами и клиентами, руководитель видит свой отдел, а чужие данные остаются закрытыми, если доступ не выдан осознанно.
Эта страница объясняет модель доступа. Настройка живёт в разделе администрирования портала — см. Администрирование портала.
Роли
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
В основе доступа лежат три роли:
- Администратор — настраивает портал, права и политики; видит и управляет широким контуром.
- Руководитель — отвечает за свой отдел или направление; видит работу своей команды.
- Сотрудник — работает со своими задачами, клиентами и материалами.
Роль задаёт базовый уровень доступа, а точные права уточняются политиками по областям и модулям.
Области доступа
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
Доступ выдаётся не «ко всему сразу», а по областям. Область — это границы, в которых действует право: компания целиком, отдел, воронка, этап, проект или конкретный пользователь.
Так один и тот же сотрудник может иметь широкий доступ в своём проекте и никакого — в чужом. Это позволяет открывать ровно то, что нужно для работы, не раскрывая лишнего.
Права: читать, изменять, управлять
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
В каждой области право складывается из уровней:
- Читать — видеть объекты и их содержимое;
- Создавать — заводить новые объекты;
- Изменять — редактировать существующие;
- Управлять — настраивать доступ и правила в этой области.
Разделяйте уровни осознанно: право видеть не означает право менять, а право работать не означает право раздавать доступ другим.
Что настраивается в правиле
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
В селекторе модуля доступны не только задачи и CRM, но также рабочие процессы, чаты, проекты, пользователи, компания, время, автоматизация, AI-помощник, операционные разделы и документы. Для каждой политики отдельно выбираются область (компания, отдел, воронка, этап, проект или пользователь) и роль.
Для отдела можно выбрать источник значения: явное правило, наследование от родительского отдела или резервный режим модуля. Флажок наследования на дочерние отделы распространяет правило вниз по структуре; проверьте его перед сохранением. В явном правиле права Создавать и Управлять настраиваются отдельно от чтения и изменения.
Для задач дополнительно задаются направления передачи: вниз, вверх и между отделами. Можно ограничить передачу руководителями или всеми сотрудниками, выбрать только прямой уровень или всю цепочку, указать целевые роли и списки разрешённых/запрещённых пользователей. Это не меняет видимость объектов — это отдельное правило назначения.
Для CRM режим видимости сделок и доступ к конкретной воронке или этапу живут в той же политике. Если правило не должно быть привязано к воронке/этапу, оставьте эти поля пустыми; иначе можно случайно сузить или расширить область действия.
Для модулей, у которых есть схема автоматизации, ниже прав CRUD отображаются отдельные возможности. Для каждой возможности выберите Разрешить, Запретить или Наследовать; это не заменяет права чтения, изменения и управления. Можно применить действие ко всем возможностям сразу. В политике ассистента доступны безопасные пресеты только для ответов, для ответов и действий или возврата к наследованию — они задают права, но не запускают автоматизацию и не меняют данные.
Если правило отдела использует наследование от родителя или резервный режим модуля, отдельные переключатели возможностей недоступны: сначала выберите явный источник. Если схема возможностей ещё не загружена или для модуля её нет, блок показывает это состояние и не должен заменяться ручным вводом технического имени capability.
Для Operations сначала показываются права, относящиеся к самому операционному модулю, с понятными локализованными подписями. Уже сохранённое в политике право остаётся видимым и тогда, когда не входит в обычный список модуля: его можно проверить и изменить явным действием. Более короткий список не снимает доступ — перед сохранением проверьте Разрешить, Запретить или Наследовать у каждого видимого права и не вводите техническое имя вручную.
Отмена и проверка изменений
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
Удаление правила и возврат ревизии требуют отдельной причины. В истории можно раскрыть подробности длинного изменения и применить ревизию, после чего система снова попросит причину. Для CRM администратор также может запустить проверку доступа в режимах Explain (почему право получилось таким) и Simulate (что произойдёт для выбранного контекста); это диагностическая проверка и она не меняет политику.
Режим доступа по умолчанию
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
Для модулей задаётся режим доступа по умолчанию — что происходит, когда явного правила нет:
- Строгий — по умолчанию доступ закрыт; открывается только то, что явно разрешено политикой. Подходит для чувствительных данных и крупных компаний.
- Открытый — по умолчанию доступ на чтение и работу открыт, а политики ограничивают отдельные области. Подходит для небольшой команды с высоким доверием.
Начинать безопаснее со строгого режима в модулях с клиентскими и финансовыми данными и открывать доступ по мере необходимости.
История изменений и обоснование
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
Изменение доступа — управленческое решение, а не незаметная правка. Поэтому при изменении политики система просит указать причину изменения, а история правок сохраняется: видно, кто, когда и почему менял доступ.
Это важно для контроля и разбора инцидентов: если кто-то увидел лишнее или, наоборот, потерял доступ, по истории понятно, какое изменение к этому привело.
Журнал показывает изменённые поля человеческими подписями и не выводит внутренние имена полей,
служебные обозначения или технические данные. Если поле не удалось сопоставить с подписью, оно сворачивается
в обозначение +N, а не раскрывает технические данные. После сохранения правила реестр
автоматически переключается на его модуль, чтобы новая строка оставалась видимой;
проверьте её там, а затем перечитайте итоговый доступ.
Хорошие практики
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
- Выдавайте доступ по области и роли, а не «на всякий случай» на всю компанию.
- Разделяйте право видеть и право менять; право управлять доступом давайте узкому кругу.
- В модулях с клиентскими и финансовыми данными держите строгий режим по умолчанию.
- При изменении политики пишите понятную причину — она останется в истории.
- Периодически пересматривайте доступы: убирайте лишние, когда меняются роли и проекты.
Частые ошибки
Концептуальная схема, не UI-скриншот и не доказательство данных портала.
- Выдают широкий доступ на всю компанию вместо доступа по области.
- Путают право видеть с правом менять — сотрудник случайно правит чужие данные.
- Оставляют открытый режим по умолчанию в модуле с чувствительными данными.
- Меняют политики без причины — потом невозможно разобрать, почему доступ стал таким.
- Не пересматривают доступы после смены роли или завершения проекта.
Связанные разделы
Концептуальная схема, не UI-скриншот и не доказательство данных портала.