For SaaS apps where every new sign-up becomes its own organisation, enable Create Tenant for Each User in Site Settings → Tenant. This shifts the platform's behaviour from "one tenant per customer organisation" to "one tenant per signed-up user" — the right model for self-serve SaaS where individuals (not org admins) sign up.
The flow
When a new user is created under the master tenant (typically via self-registration), the platform also creates a new tenant for them. The flow:
- Anonymous visitor signs up via the self-registration form.
- The platform creates the user account in the master tenant initially.
- The platform creates a new tenant for them (with auto-generated ID).
- The user is moved into the new tenant.
- On first login, the user is prompted to provide a tenant name and tenant code.
From there, the user is the admin of their own tenant. They can add team members, configure tenant-specific settings, customise to taste.
When to disable
If you are planning to create a tenant within a custom script when a new user account is created (e.g. as part of a multi-step onboarding flow that creates the tenant, sets up initial data, and provisions the user), this setting must be disabled to prevent two tenants being created — one by the platform's default flow and another by your custom script.
The first-login tenant setup
The first time a self-registered user logs in to their freshly-created tenant, they see a setup form asking for:
- Tenant Name — their organisation or workspace name (e.g. "Acme Corp", "Jane's Personal Workspace").
- Tenant Code — a short slug used in URLs or internal references (e.g. "acme", "jane"). Often used as the subdomain in custom-domain setups.
- Any custom Tenant Information Fields you've added.
Once they submit this, the tenant is fully configured and they land on their dashboard.
Tenant onboarding
The platform optionally copies template data into the new tenant — see the Copy Data to New Tenant setting. Useful for seeding the new tenant with example records, default lookup data, sample dashboards, etc. Makes the first-use experience feel less empty.
Three real-world configurations
Example 1: Project-management SaaS
New users sign up, get their own tenant, are prompted to name their workspace, then land on a dashboard with one example project pre-created. They can invite team members or work solo.
Example 2: B2C creator tool
New creators sign up, their workspace is named after their first name + last name initial by default. The platform skips the tenant-name setup form because it's auto-generated. They start using the tool immediately.
Example 3: Multi-step onboarding with payment
New users sign up, but the tenant isn't created immediately — they're shown a payment form first. A custom script then creates the tenant after successful payment. Create Tenant for Each User is disabled to prevent the default flow from creating a duplicate.
Tip: For self-serve SaaS, the smoothest onboarding has the smallest tenant-setup form. If you can derive a sensible default name from the user's data (e.g. their email's domain becomes the tenant name), skip the form entirely. Friction at this stage is a major drop-off point in conversion funnels.