Managing multiple clients
Work for one client should never be one wrong click away from another client audience.
This describes a design, not a running service
The problem
Most teams separate clients by being careful. One shared account holds every connected page, one calendar holds every schedule, and the only thing standing between a client draft and the wrong audience is the person looking at the screen at 6pm. When somebody leaves the team, the separation leaves with the habit.
How the product is designed
- A project is the unit of separation. Connected accounts, drafts, queues, media and receipts belong to a project, and a member sees only the projects they were added to.
- The separation is enforced three times: at authentication, in the application service that authorizes the action, and in the database itself through row level security. Being signed in is never treated as permission.
- Reporting follows the same boundary, so a per client report is the default shape rather than a spreadsheet someone assembles by hand.
What is actually built
Projects, project scoped membership and the row level security policies behind them are built and tested, including tests that attempt cross-project reads and assert they fail. Plans are sized by how many projects a team needs. Nothing publishes to a platform from any project yet.
Found something wrong on this page
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.