Shared Datastores
A datastore can be marked as holding shared data, in which case every tenant sees the same rows.
Where to find it
Architect Panel → Data:
- Datastores — the shared-data flag on the table
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
What belongs there
- Reference lists — countries, currencies, units, industry codes.
- A catalogue you maintain that every tenant sells from or refers to.
- Standard classifications your product depends on.
The test: would every tenant have the same rows, maintained by you? If yes, share it. If each tenant would edit their own copy, do not.
Why it matters
The alternative is copying reference data into every tenant, which means it is maintained in as many places as you have customers. A new country, a changed code, a corrected spelling then has to reach all of them, and it will not.
Nobody but you should edit it
The essential caution. A shared datastore that tenants can write to is a datastore where one customer’s edit changes what every other customer sees.
Permissions on a shared store should be read for tenants and write for you, and that should be checked rather than assumed.
Changes are immediately global
Which is the benefit and the risk. Correcting a code fixes it everywhere at once; deleting a row nobody thought was used breaks it everywhere at once.
Treat edits to a shared datastore as a change affecting every customer, because they are.
Do not put customer data in one
Obvious, and it happens — usually because a table started as reference data and grew. Anything identifying a person or a customer’s business does not belong in a store every tenant can read.
They interact with tenant copying
Shared datastores are excluded from the data copied into a new tenant, deliberately. A row appearing twice for a new customer usually means a store is both shared and eligible for copying.
Review what is shared
The flag is easy to set and easy to forget. A periodic look at which datastores are shared, and whether each still should be, is worth the ten minutes.
Worked example
A platform shares country, currency and industry-code datastores, all read-only to tenants and maintained centrally. A quarterly review found a table shared during development that had since gained customer-specific rows, which was unshared and split.
Recommendations
- Share what you maintain, not what tenants edit.
- Read-only to tenants — verify, do not assume.
- Treat an edit as a global change.
- Review the shared list periodically.