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