Управление несколькими клиентами
Работа для одного клиента никогда не должна быть в одном неверном клике от аудитории другого клиента.
Здесь описан дизайн, а не работающий сервис
Проблема
Большинство команд разделяют клиентов с помощью осторожности. Один общий аккаунт хранит все подключённые страницы, один календарь хранит всё расписание, и единственное, что стоит между черновиком клиента и не той аудиторией, это человек, смотрящий на экран в 18:00. Когда кто-то уходит из команды, разделение уходит вместе с этой привычкой.
Как спроектирован продукт
- Проект является единицей разделения. Подключённые аккаунты, черновики, очереди, медиафайлы и квитанции принадлежат проекту, и участник видит только те проекты, в которые он добавлен.
- Разделение применяется трижды: при аутентификации, в сервисе приложения, авторизующем действие, и в самой базе данных через защиту на уровне строк. Факт входа в систему никогда не считается разрешением.
- Отчётность следует той же границе, поэтому отчёт по отдельному клиенту является формой по умолчанию, а не таблицей, которую кто-то собирает вручную.
Что действительно построено
Проекты, членство в рамках проекта и политики защиты на уровне строк за ними построены и протестированы, включая тесты, которые пытаются выполнить чтение между проектами и проверяют, что это не удаётся. Тарифы рассчитываются по числу проектов, нужных команде. Пока ни из одного проекта ничего не публикуется на платформу.
Нашел что-то не так на этой странице
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.