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 attribute source choice. 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.
Start with the values that connect
In this illustrative setup, Customer has a custom text field accountId. Account has the built-in externalId plus custom accountName and plan fields.
- Maya: a Customer with
accountIdset tostudio-northand her own email and preferences. - Daniel: another Customer with the same
accountIdand his own email and preferences. - Studio North: one Account with
externalIdset tostudio-northandplanset toPro.
Both people should resolve to one shared account. The stored ID is a value; the evaluated definition below is the rule that turns it into a related record. If either side is missing or uses a different identifier, the lookup will not find the intended account.
Create one
Open Settings, then Schemas, pick the schema, then the Attributes tab, then Create attribute. Choose Evaluated attribute under How is the value set?, 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" |
A relationship can start on an object too. An Order can resolve its Product through a shared product identifier, and a contact's Recent orders can expose those products when you select the nested relationship. Define each link and its match keys explicitly.
For a shopper with several orders, create Recent orders on Customer and ask for completed Orders whose customerId equals Customer's userId, newest first by purchasedAt, limited to three. Check many cardinality. A customer with four qualifying orders should return the latest three, and a customer with none should return an empty list.
If one person belongs to several accounts and has a different role in each, a single accountRole on the person is insufficient. You can model each membership as an Object with the person's identifier, account identifier and role, then define evaluated lookups through those membership records. This is your data model; maxclicks does not add membership records automatically.
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 scheduled evaluated attribute is different: it reads a published event calculation with a measured window and freshness. An older publication can remain visible for inspection, but an enabled unavailable or expired result blocks a new decision that requests it. A paused definition with a retained publication can use that last result. 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. Evaluated and scheduled evaluated fields have a checkbox: select an evaluated relationship to run its lookup, or select a scheduled evaluated attribute to read its published value. Your copy can then reference the selected result. 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. Scheduled evaluated 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
An evaluated field can depend on another evaluated field, which makes nested lookups 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.