Migrating companies and tenants to accounts
Plain has merged what used to be two separate concepts — Companies and Tenants — into a single, unified Accounts 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.
Introducing accounts
Accounts are our new name for Tenants, to better reflect their expanded role in Plain as they replace companies. We will automatically switch over all naming in the Plain UI to read account instead of tenants as a gradual rollout for workspaces starting on the 26th of October and finishing by the 1st of November.
For more info about what this means for Plain's API, see our API migration guide.
What accounts now include
An account is the organisation a customer belongs to. Every account has:
Name and logo — the logo is automatically inferred from the account's primary domain
Primary domain and domain aliases — all email domains that belong to this organisation
Account 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 an account back to its source of truth
Source — what created this account: API, CRM, or Email domain (created automatically from an email domain)
How accounts are created
There are three ways an account is created, and you can mix and match them:
Automatically from inbound support. When someone writes in, Plain matches their email domain to an existing account. If nothing matches, Plain creates a new account from their domain automatically. This is the zero-setup path — no configuration needed.
From your CRM. Run a CRM importer to populate accounts from Salesforce or HubSpot, including custom fields. Map a CRM field to a tier so accounts land in the right SLA bucket automatically.
Via the API. Create and update accounts 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 account creation from inbound support so Plain only ever holds the accounts you explicitly define.
Domains and membership
An account 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 account. All conversations from any of those domains land in one place.
A customer can also belong to more than one account. 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.
Migrating existing workspaces
If your workspace already has companies or a previous account setup, follow these steps to migrate.
Step 1: Set up accounts
Before hiding companies, make sure your accounts are in place. Choose the approach that fits your stack:
Let Plain auto-create accounts from email domains (zero setup)
Import from your CRM via the Salesforce or HubSpot integration
Create accounts programmatically via the API, keyed on
externalId
Step 2: Enable the migration
Go to Settings > Tenants
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.
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.
Step 4: Wait for Tenants to be renamed
Workspaces will be gradually migrated by Plain automatically to go from displaying 'tenant' to 'account'. When this happens we will also automatically remove any remaining company specific configuration that was not updated in step 3 to an equivalent account setup.
After migration
Once companies are hidden and the rename has happened, accounts are the single model for all account context in Plain:
Reporting — break down support volume, response times, and SLA compliance by account or account field
Slack channel associations — associate any account 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 accounts via the API, or want to talk through the right data model for your setup, get in touch with our team.