Один пользователь работает с несколькими организациями: как спроектировать кабинет

Подготовлено 23 октября 2026 года

Если пользователь работает с несколькими организациями, кабинет должен явно показывать, от чьего имени он действует. Выбранный контекст связывают с объектами и разрешёнными действиями. Одного списка компаний в меню недостаточно, особенно при переходе по прямой ссылке или незавершённой заявке.

Назовите единицу рабочего контекста

Учебный представитель работает с условными компаниями «Альфа-пример» и «Бета-пример». В первой он вправе создавать заявки, во второй — только смотреть согласованные документы. Членство в обеих организациях не означает одинаковых полномочий и не разрешает любое действие.

В постановке нужно определить, что выбирает человек: организацию, подразделение или иной согласованный контекст. Затем перечислить доступные ему роли в каждом случае. Приглашение и первоначальный допуск рассматриваются отдельно — например, в статье о приглашении пользователя в организацию.

Покажите организацию рядом с действием

Учебный экран создания заявки должен отвечать: «Организация: Альфа-пример. Действие: создать заявку». Этот контекст полезно видеть рядом с составом и подтверждением, а не искать в настройках профиля. Если одно и то же действие выглядит одинаково для двух компаний, риск неверного выбора остаётся даже при наличии переключателя.

Опишите переход между контекстами

Допустим, человек начал З-А и переключился в Бета-пример. Владельцу процесса нужно решить, что происходит с начатым действием: черновик сохраняется за Альфа-пример, переход требует подтверждения или применяется другой понятный порядок. Молчаливый перенос состава между компаниями не должен возникать по умолчанию.

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

Разделите объекты компаний

Для каждой операции опишите организацию объекта и право текущей роли. Например, З-А нельзя превратить в заявку Бета-пример только изменением подписи на экране. Просмотр документа Д-Б также не даёт права изменить его или открыть все документы второй организации.

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

Проверьте прямую ссылку на объект

Откройте в контрольном сценарии ссылку на З-А, когда выбран контекст Бета-пример. Нужно согласовать понятный результат: доступный переход в верный контекст после проверки прав либо объяснение недоступности. Автоматическая смена организации без проверки полномочий не считается решением.

Отдельный пример — ссылка на объект, к которому у пользователя нет допуска ни в одном контексте. Ожидаемый ответ не должен раскрывать чужие сведения. Конкретный механизм и фактическую защиту проверяют разработчик и проверяющий на реализации, а не выводят из текста статьи.

Что передать разработчику

Для доработки корпоративного кабинета начните с одной операции, матрицы контекстов и сквозного пути З-А. Сначала стоит оценить возможности существующего кабинета; переход к созданию нового портала или всей ERP этим вопросом не предполагается.

Пользователь и доступные организации:
Роль / разрешённые действия в каждом контексте:
Где контекст показан перед подтверждением:
Организация объекта / его идентификатор:
Начатое действие при переключении — правило:
Прямая ссылка в другом контексте — ответ:
Недоступный объект — ожидаемый запрет:
Сквозной пример / свидетельство проверки:

Если такой участок есть в вашем проекте, опишите одно действие и нужный результат. Первый разговор бесплатный; готовое ТЗ не обязательно. Обсудить свою задачу.