Connecting records
Connect a customer to the order, account or subscription that explains the message you want to send. Relationships make that context available beyond the contact profile, so a campaign can use the relevant purchase or renewal details.
You connect them with an evaluated field: the Evaluated on demand attribute type. You describe what you want in plain language, maxinja works out the logic, and the value is calculated fresh every time something asks for it.
Create one
Open Settings, then Schemas, pick the schema, then the Attributes tab, then Create attribute. Choose Evaluated on demand as the type, name the field, and write a prompt:
Return the Account whose externalId equals this Customer's accountId. Return one account, or no record when there is no match.
Type @ in the prompt to reference this record's own fields. maxinja decides on its own whether the answer is a value or one or more related records, and shows you a plain-language description of what it built. Review the target schema and the one or many cardinality as well as the description. Specify the actual join fields, the no-match behavior and, for lists, order and limit. Test one known match and one no-match record before using the relationship.
One field type, three jobs
Links, calculations, and lookups are all the same attribute here:
| What you want | What you write |
|---|---|
| A link to another record | "The company this contact works for" |
| A calculation | "Total spent on completed orders in the last 30 days" |
| A lookup | "Their most recent order" |
And links chain. Once a contact can reach its company, the company's own computed fields are reachable from there too: its orders, its top product, whatever you described on that schema.
Read the source at the right time
An evaluated relationship resolves the available source record when requested. Updating the account name changes a later lookup without copying that name onto every customer. It does not make an upstream sync more current than it is.
A background computed attribute is different: it reads a published event calculation with a measured window and freshness. An old value can remain available while refresh is delayed. Use the attribute comparison when deciding which kind of field your campaign needs.
Where the connected data shows up
An evaluated relationship runs when a consumer requests it. Select only the relationships and nested fields that consumer needs.
In the email editor, the Data panel lists the fields available to your content. Stored fields are always there. Computed fields have a checkbox: tick one and maxclicks works it out for every recipient of this email, and your copy can then reference it. The same choice exists on workflow steps that read a record.
The choice belongs to the email or the step, not the record. The same contact can go into two different emails and each one pulls in different connected data. A later evaluated lookup can see a newly supplied order. Computed attributes used by an active broadcast revision or workflow root run retain their selected published generation; a current profile preview can therefore differ from that run.
Generating the field spends credits once, when maxinja writes it. Working the value out afterwards is a database query rather than an AI call, so using it in a large broadcast does not multiply your AI costs.
Keep the chain pointing one way
A computed field can build on another computed field, which is what makes deep links possible. It also means you can build a loop: field A defined in terms of B, and B defined in terms of A. Nothing stops you at the point you save it, and neither value can ever be worked out afterwards.
Sketch the dependencies before nesting them. A relationship in each direction can be useful, but do not define a field in terms of a chain that requires itself. Expansion detects a circular dependency and fails.
Next
Go deeper in the evaluated attributes reference, or get your records in with getting your data in.