Attribute expansion
Expansion selects the extra customer context an email or workflow will receive. It covers both evaluated attributes, which run a relationship or calculation on demand, and computed attributes, which read a published background result.
A renewal email might need a subscription relationship and a recent activity count. Another message to the same contact may need neither. Select the fields at the point of use so you can see which customer context the content depends on.
Turn one on for an email
Open the email's Data panel and expand its record property. Stored writable fields are part of the record. Fields that need expansion have checkboxes; select the ones your content uses.
An unselected attribute is absent from the rendering context. Its result then depends on your Liquid fallback or AI instruction, rather than on the underlying customer data. Merely mentioning the key in an email does not select it.
The same choice applies to templates, broadcasts and a workflow's Send Email step. Use the record schema in the Data tab to confirm the exact path after selecting it.
Go one level deeper
An evaluated relationship that returns records can be expanded further. Selecting subscription exposes the subscription's stored fields. Select one of its evaluated or computed attributes if you also need that value.
A relationship returning many records gives an array. Define a useful order and limit, such as “the three most recent completed orders, newest first,” then loop through those records in the email. A single-record relationship gives one record or no match. A JSON result is a value rather than another branch of record relationships.
Dependencies required by an evaluated field are resolved automatically. They are not added as extra output fields unless you also selected them.
Check it returns what you think
Open a real contact or object and use the field's Compute value action to inspect it. For an evaluated attribute, this runs its current definition. For a computed attribute, reading the field retrieves its published calculation; it does not force a new calculation of event history.
In the editor, select a real record as sample data and load the selected expansions. The resulting preview checks actual available values for that record. Generate with AI and manually entered sample data are useful for layout and fallback testing, but do not prove that your source records or relationships are correct.
Test a typical customer, one with no matching history, and one with several related records. For computed attributes, also check Data through in the attribute's publication status.
In a workflow, maxinja sets it for you
When maxinja generates a step's logic, it records the fields that logic needs. Review the step's Reads to see the context it will request. The AI and HTTP Request steps also let you choose Expected data explicitly, while an email has its own data selection.
Evaluated relationships can read changed records at a later step. Computed attributes follow a different rule: a workflow root run and its child runs share the published-generation selection frozen for that run. A newer background publication does not silently change that selection.
Know how fresh the value is
| Expanded field | What the read returns | What to check |
|---|---|---|
| Evaluated | A calculation against the records currently available to maxclicks | Whether the source system has supplied the latest data, and whether the relationship/filter is correct |
| Computed | The latest available published generation, or the generation selected for that operation | Its measured window and freshness; an old published value can remain available while refresh is delayed |
A broadcast revision and a workflow root run pin their computed-attribute generations when that consumer first establishes its read context. That selection includes attributes with no publication yet. Later publications do not fill them in for the existing consumer, and an erased or unavailable pinned generation fails the read rather than switching to a newer one. A standalone sample can therefore differ from an already running campaign.
A computed attribute with no publication or no matching subject value resolves to empty. Empty is different from zero. An evaluated one-record relationship with no match returns no record. Give your content an appropriate fallback for both cases.
An API template send can upsert the record data in its input before loading the selected expansions. Supplying a first name along with an identifier may therefore update the contact. Send only the identity fields when your intent is to look up existing data.
What it costs
Generating an evaluated definition uses AI; executing that definition is a data lookup. Nested relationships increase the number of reads. A computed attribute reads a published result instead of rerunning its event calculation for every recipient.
Choose the context the message needs. Narrow a relationship in its definition instead of fetching every record and discarding most in the template. Many-record relationships are capped at 1,000 records, with excess results truncated and a warning.
Expansion can fail when a generated definition is missing or invalid, a JSON result does not match its declared shape, or a dependency chain loops back on itself. Review the failing field and definition instead of treating every error as an empty match. A busy lookup service can also time out; inspect the operation's error before retrying.
Where computed values do not appear
Plain public API record reads and listings return supported stored record data. They do not expose evaluated relationships or computed-attribute expansion switches. Use the configured email and workflow data flows described here, and consult the Records API for its actual response contract.