Per-Tenant Configuration

Per-Tenant Overrides

Instance configuration is held per tenant, so a setting can have a different value for each customer.

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 → Configuration:

• Instance Configuration Fields — the fields themselves

The configuration-field family as a whole — user, tenant and instance fields — is covered under Development. This article is about what varying a value per tenant means in practice.

What genuinely varies

• Credentials — each tenant’s own payment gateway, mail service or integration account.
• Endpoints — where a tenant’s data goes.
• Limits and thresholds agreed commercially with that customer.
• Branding and presentation values.

Credentials are the important case. Per-tenant credentials are what allow each customer to have their own Stripe account, their own mail sender and their own integrations — which is usually what they want and sometimes what they require.

What should not

Anything security-relevant. A tenant with weaker password requirements, a longer session timeout or a relaxed verification rule is a tenant that is your weakest link, and the reason will be that somebody found it inconvenient once.

Security settings should be installation-wide, and the answer to "can we have it looser" should be no.

Defaults do the work

Most tenants should be on the default for most settings. An override is a deviation, and deviations are what nobody remembers when diagnosing why one customer behaves differently.

Being able to list which tenants have overridden what is more valuable than the overrides themselves.

Encrypt the secrets

Per-tenant credentials are the most sensitive thing in the configuration. Fields holding them should be marked encrypted, and access to the screen kept to a very small group.

New tenants need theirs set

A tenant onboarded without its integration configuration has a feature that fails at the moment somebody first tries to use it. Put the required values on the onboarding checklist rather than discovering them by failure.

Review overrides periodically

They accumulate — set for a trial, for a migration, for a problem long since fixed. A list of every tenant that differs from the default, with a reason for each, is a short and revealing document.

Retired integrations leave credentials behind

Per tenant, so there are more of them. When a customer stops using an integration, clear its configuration rather than leaving live credentials for a system nobody uses.

Worked example

A platform holds each tenant’s payment and mail credentials as encrypted per-tenant configuration, set during onboarding from a checklist. Security settings are installation-wide with no per-tenant override permitted. An annual review lists every deviation and its reason.

Recommendations

• Vary credentials, never security settings.
• Encrypt every credential field.
• Put required values on the onboarding checklist.
• Review deviations annually with a reason for each.

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.