Управление несколькими клиентами
Работа для одного клиента никогда не должна быть в одном неверном клике от аудитории другого клиента.
Здесь описан дизайн, а не работающий сервис
Проблема
Большинство команд разделяют клиентов с помощью осторожности. Один общий аккаунт хранит все подключённые страницы, один календарь хранит всё расписание, и единственное, что стоит между черновиком клиента и не той аудиторией, это человек, смотрящий на экран в 18:00. Когда кто-то уходит из команды, разделение уходит вместе с этой привычкой.
Как спроектирован продукт
- Проект является единицей разделения. Подключённые аккаунты, черновики, очереди, медиафайлы и квитанции принадлежат проекту, и участник видит только те проекты, в которые он добавлен.
- Разделение применяется трижды: при аутентификации, в сервисе приложения, авторизующем действие, и в самой базе данных через защиту на уровне строк. Факт входа в систему никогда не считается разрешением.
- Отчётность следует той же границе, поэтому отчёт по отдельному клиенту является формой по умолчанию, а не таблицей, которую кто-то собирает вручную.
Что действительно построено
Проекты, членство в рамках проекта и политики защиты на уровне строк за ними построены и протестированы, включая тесты, которые пытаются выполнить чтение между проектами и проверяют, что это не удаётся. Тарифы рассчитываются по числу проектов, нужных команде. Пока ни из одного проекта ничего не публикуется на платформу.
Questions
Does this workflow run today?
Not end to end. No connector is verified in production, so nothing described on this page publishes anywhere yet. The section on what is actually built says which parts exist.
Will it use unofficial ways to post?
No. Publishing goes only through each platform's official API. There is no browser automation, no scraping and no automated engagement.
Нашел что-то не так на этой странице
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.