Tenant Parameters
Tenant parameters are named configuration settings scoped to a single tenant. They give administrators a controlled way to adjust platform behaviour for their organisation without code changes, and they let the platform deliver tenant-specific defaults, feature toggles, and integration values that modules pick up automatically.
What a parameter represents
A parameter is a single piece of configuration data identified by a stable code. Modules and platform features look parameters up by their code at the moment they need a setting — for example, when sending a notification, processing an invoice, or rendering a tenant-branded page.
Because parameters are tenant-scoped, two tenants can use the same parameter code with different values and neither affects the other.
Parameter structure
Each parameter is made up of a small set of attributes:
| Attribute | Purpose |
|---|---|
| Code | Stable identifier used by the platform to look the parameter up |
| Value | The configured value for the tenant |
| Localised value | Optional translated value for tenants that operate in multiple locales |
| Description | Human-readable explanation of what the parameter controls |
| Validity period | Optional dates that control when the value takes effect and expires |
| Encryption flag | Indicates whether the value is stored encrypted |
The code is the contract between the platform and the parameter: it does not change. The value can be edited freely, and the description gives administrators context on what they are editing.
Time-bounded validity
Parameters can carry a start date, an end date, or both. The platform only treats a parameter as active when the current date falls within its validity window.
This makes it possible to:
- Schedule a configuration change in advance, so it switches over automatically on a planned date.
- Retire an old value on a known cut-off date without having to delete the parameter.
- Maintain a history of past values for audit purposes — superseded parameters remain visible but no longer affect behaviour.
When more than one parameter shares a code, the platform uses the validity dates to pick the value that applies right now. A parameter without validity dates is treated as always active.
Encrypted parameters
Some configuration values are sensitive — for example, integration credentials, signing secrets, or third-party API keys. These parameters can be marked as encrypted, in which case the platform stores the value in an encrypted form and only decrypts it when a feature legitimately needs to use it.
Encrypted parameters behave identically to unencrypted parameters from the perspective of the modules that consume them — the code, description, and validity rules all work the same way. The difference is that the underlying value is never visible in plain text outside the controlled paths that consume it, and the platform's normal viewing screens display a masked placeholder rather than the secret itself.
This allows sensitive configuration to live alongside ordinary configuration without leaking through audit logs, exports, or administrator screens.
Scope and management
Tenant parameters are managed within the tenant they belong to. They are isolated from other tenants in the same way as all other tenant data — a parameter created in one tenant is invisible to every other tenant on the platform.
Administrative permissions control who can view, create, and edit parameters within a tenant. Because parameters often govern integrations and platform behaviour, the ability to change them is typically reserved for tenant administrators rather than ordinary users.
How modules use parameters
Modules and platform features read parameters at the point they need a configuration value. Typical uses include:
- Defaults for new records (for example, a default billing profile, currency, or country).
- Feature toggles that enable or disable optional behaviour for a tenant.
- Integration endpoints and credentials for connecting to external systems.
- Branding values such as support email addresses or display strings.
Because lookups happen by code at runtime, changing a parameter value takes effect the next time a feature reads it — there is no separate deployment step required.
Related topics
- Tenants and Multi-Tenancy — how tenant isolation applies to parameters and other tenant-scoped data
- Lookups and Reference Data — a complementary mechanism for tenant-scoped enumerations and key-value settings