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.