The Copy Data to New Tenant setting controls whether template data is automatically copied from the master tenant into each newly-created tenant. Done right, this makes new tenants feel populated and ready-to-use from the moment they're created instead of empty and intimidating.
What gets copied
Data from the master tenant for all datastores in the .tables table where appinitmode is 2 or 4 AND tenantshareddata is 0. That combination means:
- The datastore is supposed to be initialised for new tenants (
appinitmode > 0). - The datastore's data is per-tenant (
tenantshareddata = 0), not shared across tenants.
For each matching datastore, every row from the master tenant is copied into the new tenant. The copy preserves field values but assigns new row IDs (since each tenant's database might have its own ID sequence in separate-database mode, and even in shared mode the rows are new logical records).
What doesn't get copied
- Datastores with
tenantshareddata = 1— those are shared across tenants by reference, not copied. - Datastores with
appinitmode = 0or other modes that don't trigger auto-init. - User accounts — each tenant has its own users; nothing is copied.
- Audit logs and history — clean slate for each new tenant.
Three common use cases
1. Pre-populating common lookup tables
Reference data like product categories, countries, currencies, status options. The master tenant has the canonical list; new tenants get a copy so they start with sensible defaults but can customise.
2. Loading template documents or email templates
Each tenant might need a starter set of document templates (invoices, quotes, contracts) and email templates (welcome, reset, notification). Set them up once on the master tenant; new tenants get their own copy that they can edit without affecting other tenants.
3. Seeding sample data for the first-run experience
Pre-populate example customers, sample orders, demo dashboards so the new tenant's UI doesn't look empty on first login. The user can delete the samples once they're ready to add real data.
Configuring which datastores copy
The decision per datastore is made via two fields on the .tables system row:
- appinitmode —
- 0: don't auto-init on new tenant.
- 1: create the table structure but no data.
- 2: create structure + copy data from master.
- 4: create structure + copy data + run any registered init scripts.
- tenantshareddata — 0 for per-tenant data; 1 for shared data (one copy referenced by all tenants).
For each application-level datastore you create, decide which combination is right and configure accordingly.
Three real-world copy patterns
Pattern 1: Per-tenant with template seed data
A Customers datastore. appinitmode = 2 (copy from master), tenantshareddata = 0 (per-tenant data). New tenants start with whatever sample customers you've put in the master, but they can edit freely without affecting other tenants.
Pattern 2: Shared reference data
A Countries lookup datastore. appinitmode = 2, tenantshareddata = 1. Every tenant references the same Countries list. Changing the list affects everyone — usually that's what you want for reference data like this.
Pattern 3: Per-tenant empty
A Customer-specific datastore where each tenant fills it in themselves. appinitmode = 1 (create structure only), tenantshareddata = 0. New tenants get an empty table they can populate.
Tip: Don't go overboard with seed data. New tenants don't want to wade through ten sample customers and twenty sample orders just to find where to add their first real one. A handful of carefully-chosen examples (one or two per table) is enough to show what the platform can do without becoming clutter.