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 scheduled evaluated attributes, which read a published background result.
Suppose Customer has an evaluated account relationship. Maya's own name and email are already in the email data. Selecting account also supplies the matching Account object's stored name and plan. If you need an evaluated field on that account, select that nested field too.
- Greet Maya: use the contact's stored
firstName. - Mention Studio North's plan: select the contact's
accountrelationship, then use that account's stored name and plan. - Refer to a published activity count: select the relevant scheduled evaluated attribute to read its selected publication.
The keys above are illustrative custom fields. Use the exact paths your editor shows. Another email to Maya can select different context without changing her record or the relationship definition.
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 scheduled evaluated 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 scheduled evaluated 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 scheduled evaluated 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. Scheduled evaluated 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 |
| Scheduled evaluation | The publication selected for the decision, with its definition revision and freshness policy | Whether a complete publication exists and meets the cadence; paused definitions can use a retained last publication |
A broadcast revision and a workflow root run pin their scheduled evaluated publications, definition revisions and freshness policy 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. Freshness is assessed against the captured decision time. A standalone sample can therefore differ from an already running campaign. A definition replacement that invalidates the captured selection requires the existing decision to be resolved; it cannot switch silently to new logic.
A valid scheduled publication with no matching subject value resolves to empty. No complete publication is unavailable and fails a decision that requests it. An enabled definition with an expired publication also fails a new decision; it does not silently pass an old value to the email. A paused definition with a retained publication can read its last published result. Empty history, unavailable calculation and a measured zero are different states. An on-demand one-record relationship with no match returns no record, so give that genuine no-match case a fallback.
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 scheduled evaluated 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 evaluated values do not appear
Plain public API record reads and listings return supported stored record data. They do not expose evaluated relationships or scheduled-attribute expansion switches. Use the configured email and workflow data flows described here, and consult the Records API for its actual response contract.