How do I give a client read-only CRM access?
Use a role with read scopes on the objects the client may see, and no write, send or export rights. For agencies with several clients, prefer a separate instance per client, so read-only is enforced by tenancy, not by a checkbox that could be wrong.
The short answer
- Give a client a role scoped to read access on exactly the objects they should see, with no write, send or export rights. Not a broad role with read-only framed as a UI restriction.
- For an agency managing several clients in one shared CRM instance, a role-based read-only setting depends on every feature filtering by client correctly, forever. A missed filter can leak one client's data into another's view.
- A separate instance per client removes that risk structurally. There is no shared system in which a filtering bug could expose one client's pipeline to another. The two clients' data was never in the same database.
- Read-only access should exclude export by default. A role that lets a client view records but also export them as CSV grants a durable offline copy of everything visible. That is a materially larger permission.
Why a role-based restriction and true isolation are not the same guarantee
A role that marks a user read-only inside a shared, multi-client CRM depends on code being correct at every layer. Every query for every feature has to scope its results to what that role should see, forever, across every future feature anyone builds. That is a real and ongoing engineering commitment. It only takes one missed filter, in one feature, at one point in the product's life, for a client to see data they should not.
A separate instance per client sidesteps this entirely. If client A's data lives in a database client B's account has no connection to, there is no query that could expose client A's data to client B. The two were never in the same system. This is a stronger guarantee because it does not depend on every future line of code being correct. It depends on the two databases being separate, which is verified once rather than with every release.
Approach, what it protects, what it does not
| Approach | What it protects | What it does not |
|---|---|---|
| Role-based read-only in a shared instance | Prevents the client from writing, sending or deleting | Depends on every query correctly filtering by client; a bug can leak data |
| Role-based read-only plus export disabled | Also prevents a durable offline copy of visible data | Still depends on correct filtering everywhere the data is queried |
| Separate instance per client | Removes the possibility of cross-client leakage structurally | More operational overhead to provision and maintain per client |
What this looks like for an agency specifically
An agency giving a client a view of their own pipeline, without letting them edit records, send messages or export the data, needs two pieces working together. A role that restricts to read-only with no export. And, if several clients share one platform account, isolation strong enough that read-only is guaranteed by architecture rather than by a permission flag someone has to get right every time.
Disclosure: SalesCrew is our product, and it is built single-tenant by design. Each client gets a dedicated Supabase project rather than sharing one database with other clients through role-based filtering. For an agency giving a client read-only visibility into their own instance, the same three-axis scope model (channel, profile, area) that governs every user's access applies, restricted to read, with no write, send or export rights on that role.
Read-only in a shared tenant still shows other clients' data if a filter is wrong
Questions
- What is the difference between a role-based read-only setting and tenancy-based isolation?
- A role-based setting is a permission flag inside a shared system. It is only as reliable as the code enforcing it and the filters on every query. Tenancy-based isolation means the client's data lives in a separate instance. There is no shared system in which a bug or a missed filter could expose someone else's data.
- Why would an agency prefer separate instances over a shared one with roles?
- A shared multi-client instance depends on every query filtering correctly by client, forever, across every feature anyone builds. A missed filter in one feature can leak one client's pipeline into another's view. Separate instances make that class of bug structurally impossible.
- Does read-only access ever need to include exports?
- Usually not, and this is a common oversight. A read-only role that still allows CSV export gives the client a durable copy of everything they can see. That is a different and larger permission than viewing it in the product.