Multi-Tenant for Service Networks: One Install, N Brands

Most CRMs sell "multi-company" as an upgrade. You pay more, and a dropdown appears in the corner. The data underneath is still one big table with a companyId column nobody enforces. That works until two things happen at once: a partner asks for their own brand, and an audit asks you to prove isolation.

What "multi-tenant" actually means

There are three layers, and a real multi-tenant CRM enforces all three:

1. Data layer

Every row carries a companyId. Every query filters on it. Every relation respects it. That's table stakes — but the enforcement matters: it has to be at the service boundary, not the UI. Hide-by-CSS isn't isolation.

In practice this means:

• Foreign keys that cascade per tenant
• Indexes that always start with (companyId, ...)
• API handlers that resolve companyId from the session and never trust the URL

2. Mail layer

The forgotten one. If two tenants share a mail server, they share a sending reputation. Tenant A's spam complaint hurts Tenant B's deliverability. So a real multi-tenant setup gives each tenant:

• Their own domain (@tenant-a.com)
• Their own DKIM key
• Their own SPF / DMARC posture
• Optionally, their own warming schedule

3. AI layer

The newest one, often missed. If two tenants share an LLM context window, they share leakage risk. A real multi-tenant AI integration:

• Routes prompts per companyId with no shared state
• Uses tenant-owned API keys (so usage is billed per tenant)
• Tags every generation with the tenant for audit
• Never builds a cross-tenant embedding index without explicit consent

Where it matters

Three concrete cases:

Agency holding companies

A parent agency with three sub-brands needs:

• Three separate sales pipelines (different clients, different positioning)
• One unified team directory (consultants flex across brands)
• Three mail domains, each with its own outreach reputation
• Cross-brand reporting for the holding company

Most CRMs force you to pick: separate accounts (and lose cross-brand reporting) or shared account (and lose brand isolation). A real multi-tenant model gives both.

Multi-practice consultancies

A consultancy with engineering, environmental, and legal practices doesn't want lead overlap. The engineering practice qualifies leads on technical fit; the legal practice on regulatory exposure. Same firm, different filters.

Tenant-per-practice with shared team gives you that.

Franchisee networks

A franchise where each location runs its own pipeline but reports up to corporate. Each franchisee owns their leads (data sovereignty). Corporate sees rolled-up metrics (governance). Different brands but shared playbooks.

The cost of doing it wrong

Retrofitting multi-tenancy is the second-hardest migration in software, after a database engine swap. Every shared table becomes a foot-gun, every shared mail domain becomes a deliverability risk, and every shared AI context becomes a privacy risk.

The fix is to start multi-tenant from day one, even when you only have one tenant.