Migrating companies to tenants

Plain has merged what used to be two separate concepts — Companies and Tenants — into a single, unified Tenants model. There is now one model that does everything both used to do. New workspaces get zero-setup tenant creation out of the box, and more advanced capabilities (custom fields, tiers, CRM sync) are there when you need them.

If your workspace already uses companies or the old tenants model, this guide walks through what has changed and how to complete the migration.

What tenants now include

A tenant is the organisation a customer belongs to. Every tenant has:

• Name and logo — the logo is automatically inferred from the tenant's primary domain

• Primary domain and domain aliases — all email domains that belong to this organisation

• Tenant fields — your own custom fields such as plan, ARR, account owner, or seat count

• External ID — an identifier from your own system or CRM to link a tenant back to its source of truth

• Source — what created this tenant: API, CRM, or Email domain (created automatically from an email domain)

How tenants are created

There are three ways a tenant is created, and you can mix and match them:

1. Automatically from inbound support. When someone writes in, Plain matches their email domain to an existing tenant. If nothing matches, Plain creates a new tenant from their domain automatically. This is the zero-setup path — no configuration needed.

2. From your CRM. Run a CRM importer to populate tenants from Salesforce or HubSpot, including custom fields. Map a CRM field to a tier so tenants land in the right SLA bucket automatically.

3. Via the API. Create and update tenants programmatically using Plain's GraphQL API — ideal when your product or data warehouse is the canonical source of truth for your accounts.

If you want full control, you can turn off automatic tenant creation from inbound support so Plain only ever holds the tenants you explicitly define.

Domains and membership

A tenant can have multiple domains. This means an organisation that uses more than one email domain — or one that rebranded or was acquired — shows up as a single tenant. All conversations from any of those domains land in one place.

A customer can also belong to more than one tenant. This models real-world situations: a person might belong to a parent organisation and also a regional sub-team, each as its own tenant with its own tier, SLA, and account owner.

If you end up with two tenants that should be one — after a rebrand or an acquisition — you can merge them. Merging brings all threads, customers, and domains under a single tenant and preserves external IDs so nothing is lost.

Migrating existing workspaces

If your workspace already has companies or a previous tenants setup, follow these steps to migrate.

Step 1: Set up tenants

Before hiding companies, make sure your tenants are in place. Choose the approach that fits your stack:

• Let Plain auto-create tenants from email domains (zero setup)

• Import from your CRM via the Salesforce or HubSpot integration

• Create tenants programmatically via the API, keyed on externalId

Step 2: Enable the migration

1. Go to Settings > Tenants

2. Toggle on Hide companies. Companies are hidden across your workspace and the tenant-first view becomes active. The thread sidebar will now show tenant context instead of company context — threads matched to a tenant via domain will show it automatically.

3. Optionally toggle on Show domain-based tenants to surface automatic domain groupings for any thread that does not yet have an explicit tenant set.

Step 3: Update company specific configuration

Once companies are hidden, any configuration that still references a company will show a "Tenants are replacing companies" warning. Work through each of the following:

Thread views and filters: Saved views that filter by company will show a migration hint on the filter pill. Remove the company filter and replace it with the equivalent tenant filter.

Workflows: Conditions and actions that reference companies will show a migration hint in the workflow editor. Replace them with tenant-based equivalents. Tenant fields are fully available as both conditions and actions — for example, route a thread based on a tenant's plan, or update a tenant field when a thread is resolved.

Roles and access filters: Company-based thread access filters become read-only once companies are hidden. Remove them and replace with tenant filters to preserve your routing logic.

Help center access lists: Company-based thread access filters become read-only once companies are hidden. Remove them and replace with tenant filters to preserve your access logic.

After migration

Once companies are hidden, tenants are the single model for all account context in Plain:

• Reporting — break down support volume, response times, and SLA compliance by tenant or tenant field

• Slack channel associations — associate any tenant with a Slack channel, either as a fallback when no email is available or as a hard override regardless of email domain

Need help?

If you have a large volume of threads to migrate, need help setting up tenants via the API, or want to talk through the right data model for your setup, get in touch with our team.