How do I keep client data separate?
Run one CRM per client: a separate database, sending mailboxes and suppression list for each. A mistake in one account stays there.
Want to see it first? Book a demo
The short answer
- Agencies running outbound for several clients keep client data separate by running one CRM per client, each with its own database, not a filtered view of a shared one.
- Client data can be separated at three levels: a filter in application code, a row-level rule in a shared database, or a database per client.
- Outbound needs a second layer of separation: each client's sending mailboxes, suppression list and reply inbox stay inside that client's account.
- SalesCrew runs every client as its own Supabase project, with its own Postgres database, file storage and region, and each instance has unlimited seats.
Why a filter isn't separation
The real risk is rarely a hacker. It's an ordinary slip: a query that forgot its client filter, a permission set copied from the wrong template, a report built on the whole table. What decides the damage is how far that slip travels before something stops it.
With a filter in the app, every client's rows share the same tables. Code that remembers to ask "which client?" is the only wall. One missing condition shows your dental client a roofer's pipeline.
Row-level security moves the rule into the database, so it runs on every query. That's a big step up. But the rule and the data still share one home, and a policy written too loosely reaches every client at once.
A database per client changes the shape of the problem. No table holds two clients, so no query can cross between them. A mistake in one project touches one client.
The three levels of separation
Read the second row first. It decides the rest.
| Filter in the app | Row rule in a shared database | A database per client | |
|---|---|---|---|
| Where the rule lives | In app code, on every query a developer writes | In the database, on every query | No shared data, so no rule is needed |
| What one mistake exposes | Another client's records | Every client, if the policy is wrong | One client's own account |
| What an export contains | Files cut out of shared tables | Files cut out of shared tables | The whole database, relationships intact |
| Data residency | One region for everyone | One region for everyone | Chosen per client at setup |
Outbound adds a second layer
When you send cold email for several clients, data isn't the only thing that leaks. Sender reputation leaks too. If client A's list bounces hard from a mailbox you share with client B, both lose inbox placement. A suppression list shared across clients can also block a contact who opted out of one client but never heard from the other.
So keep each client's outbound inside that client's account. In SalesCrew each instance has its own mailbox pool, with per-mailbox and per-domain daily caps. Unsubscribes and bounces go onto that client's suppression list, and suppression is checked again at send time. Replies land in that client's shared inbox, next to that client's deals.
You still run all of it from one place. The agency console lists every client instance, and a snapshot of your best setup (pipeline stages, cadences, fields) applies to each new client you add. Your team works every account, and no account can see another.
How SalesCrew keeps each client apart
Every SalesCrew client instance is its own Supabase project: its own Postgres database, file storage and edge functions. You pick the region when the project is created. Inside an instance, row-level security and three access scopes (channel, profile and area) govern people and MCP tokens the same way. Every tool call lands in an audit log with the actor named.
When a client leaves, you hand them a full Postgres dump and CSV exports of their own data, not a file cut from a shared table. Core starts at $299 a month, and every tier has unlimited seats, so your whole team and the client's team can log in. See pricing for the tiers.
A white-label login says nothing about where data lives
Questions
- Can one CRM hold multiple businesses?
- Yes, in two ways. A shared CRM keeps every business in the same database and separates them with filters or row rules. A per-client setup gives each business its own database, so no table ever holds two clients' records.
- Is row-level security enough to keep clients separate?
- Row-level security is a real control, because the rule sits in the database and applies to every query. It still lives inside one shared database, so a policy written too loosely reaches every client at once. A separate database per client removes that failure instead of guarding against it.
- Should each client have its own sending mailboxes?
- Yes, when you run outbound for them. Separate mailboxes keep one client's bounce rate and complaints off another client's domain. They also keep replies landing in the right client's inbox, next to the right deals.
- What should I ask a vendor to confirm how separated my clients are?
- Ask whether two clients' records ever sit in the same table. Ask whether an export gives you a database or a folder of files. Ask whether one client can sit in a different storage region without moving anyone else. Those three answers come from the architecture, not the brochure.