Attributes
Tenant-scoped attribute registry with keys, display names, allowed values, and variant classification.
Attributes
Attributes let you describe why a template variant exists—for example, a Dutch version, a corporate-branded version, or an email layout. Definitions belong to a tenant and are reused across that tenant’s templates.
Attribute definitions
Create an attribute definition in the tenant’s Attributes registry. Each definition has:
- Key — A slug identifier (e.g.,
language,brand,channel) - Display name — A human-readable label (e.g., “Language”, “Brand”)
- Allowed values — An optional list of permitted values. If empty, any value is accepted
- Code list — An optional code list to provide the values instead of maintaining them inline. Choose either a code list or inline allowed values.
The key is the stable identifier used in API requests and variant data. Keep it short and consistent; use a key such as language or brand, rather than a label that may change.
Usage
After creating a definition, assign key-value pairs to template variants. For example, a template might have variants with language=nl, language=en, or brand=corporate. A variant can use several attributes at once.
Attributes serve two purposes:
- Variant classification — Variants are tagged with attribute key-value pairs (e.g.,
language=nl,brand=corporate) that describe their characteristics - Automatic variant resolution — When a render request includes attributes, the resolver matches them against variant attributes to find the best fit
Choosing a variant
A request can select a variant in either of two ways:
- Explicitly — Provide a
variantIdwhen you already know which variant to render. - By criteria — Provide attribute criteria such as
language=nl. Mark criteria as required when every selected variant must match them; optional criteria influence the preference but do not exclude a variant on their own.
The resolver first filters out variants that fail required criteria, then scores the remaining candidates by their optional matches and specificity. If no candidate matches the required criteria, rendering falls back to the template’s default variant. A request must not combine an explicit variantId with attribute criteria.
Only definitions registered for the tenant can be assigned to its variants. Values are validated against the definition when inline allowed values or a code list is configured.
In the UI
The attributes list page shows a table with columns for:
- Key — The attribute slug
- Display name — The human-readable label
- Allowed values — Displayed as badges
Clicking an attribute opens an edit dialog for modifying the display name, allowed values, or code-list source.
Documentation
Guided tour
Interactive training