One business per client vs shared

Give each client its own business when their data, team, and setup must never mix. Keep one shared business when the same team works across clients and needs one pipeline, one inbox, and reports across all of them; separate the clients inside it with locations, departments, and entry ownership.

Requirements

None to decide. To create a business: a Sonta account. To shape access inside one: a role that can manage roles.

The fork

A recruitment agency places candidates for several employers. It can run each employer as a separate business (elsewhere: workspace, tenant), or run one business for the agency and keep every employer inside it. The same fork appears for a group with several brands, or a consultancy running operations on behalf of its clients.

Option 1: one business per client

What it is. Each client gets a business of its own: its own collections, entries, roles, automations, mailboxes, and connected website.

When to pick it.

• The client's data must never be visible to anyone working for another client, and that has to hold by construction, not by configuration.
• Each client needs a different model: its own collections and fields, its own stages.
• The client's own staff will work in the system.
• The client might one day take its setup and run it without you.

What it costs.

• Nothing crosses the boundary. A report reads collections in one business, so there is no report across all clients. An automation, a mailbox, and a website each belong to one business.
• Setup repeats. Each new business starts with the CRM collections installed automatically, but any collection, field, or automation you add has to be built again in the next one. A blueprint is how to avoid rebuilding it by hand.
• Switching. People and agents work in one business at a time and switch between them. An agent working several clients has to switch deliberately; see How an agent connects.

Option 2: one shared business

What it is. One business holds every client. Each entry belongs to a client through a reference, and people see what their role and ownership allow.

When to pick it.

• One team works across clients and needs one view of the pipeline and one inbox.
• You want reports across all clients: placements this quarter by employer, revenue by account.
• The model is the same for every client.

How to keep clients apart inside it.

• Locations and departments: every entry can belong to a location and a department, and working hours and bookings follow them.
• Entry ownership: a people field can mark who runs an entry. Unless a role is allowed to see every entry, people see the entries they own plus unowned ones.
• Roles: a role scoped to the collections a person needs; see Create a custom role.

What it costs.

• Separation depends on configuration. A role or an owner set wrongly shows one client's entries to someone working for another.
• Everything is visible to administrators of the business.
• Splitting a client out later is a data migration.

Notes and limitations

• A person can belong to several businesses with a different role in each; a role in one says nothing about another. See How access works.
• The CRM variant, sales CRM or CRM with orders and a product catalog, is chosen when a business is created and cannot be changed later. Choose it per business.

Rule of thumb

If a leak between clients would be a breach, give each client a business. If the same people run the same process for all of them, share one.