Tenant-Defined Tables
A tenant can define tables of its own, with its own fields, holding data nobody else sees or shares a structure with.
Where to find it
Architect Panel → Configuration:
- Multitenancy — the tenants themselves
- Custom Tenant Information Fields — your own fields on a tenant
- Instance Configuration Fields — settings held per tenant
Architect Panel → Data:
- Datastores — the platform-wide datastores, for comparison
What it provides
Each tenant table has a name and a friendly name, and its fields carry the usual definition — type, description, default, validation, whether required, order and whether encrypted. Values are held against the table, the row and the field.
So a customer can model something specific to their business without you adding a datastore that every other tenant then carries.
When it is the right answer
- One customer needs something nobody else does, and it is genuinely theirs.
- Customers each track something similar with different shapes that cannot be reconciled into one datastore.
- A customer wants to extend the product themselves without waiting for you.
When it is not
When several tenants want the same thing. Three customers defining their own version of the same table is three structures, three sets of reports and three support conversations — where one platform datastore would have served all of them and everybody after.
If you find yourself helping a second customer build the same tenant table, build it into the product instead.
It is not a full datastore
The important limitation to state plainly. A platform datastore gets permissions, audit, retention, lifecycle, record links, workflow and reporting as a matter of course. A tenant-defined table is a simpler thing.
So anything that needs governance — anything regulated, anything with retention obligations, anything a workflow depends on — belongs in a datastore, not here.
The tenant owns the consequences
A tenant that defines its own tables has taken on the design. Badly chosen field types, missing validation and a structure that does not fit are theirs, and they will still ask you about them.
Decide how much help you offer before you offer the capability.
Watch what goes in them
Customers will put personal data in a tenant table, because it is convenient and nobody stopped them. Be clear about what governance those tables do and do not have, in writing, before enabling this.
Keep an eye on how they are used
Tenant tables tend to be created enthusiastically and abandoned. A periodic look at which exist, and which hold anything, keeps the picture honest — and tells you what to build properly.
Worked example
A platform allows tenant tables for genuinely customer-specific tracking, documented as having no retention or audit support. Two customers built similar tables for site inspections; the third request prompted a proper datastore, which all three moved to.
Recommendations
- Build a datastore once a second customer wants the same thing.
- Never for regulated or retained data — say so in writing.
- Decide how much design help you offer.
- Review what exists and what it tells you to build.