Evaluated attributes

An evaluated attribute gives a business question one reusable definition. “The subscription this customer is renewing” can become a relationship; “the total value of completed orders” can become a calculated result. maxinja generates the logic, you review its meaning, and maxclicks runs it when that field is requested.

Use evaluated attributes for on-demand relationships and calculations. For a measure of event history that should refresh on a schedule, use a computed attribute instead.

Create one

Open Settings → Schemas, choose a schema, then Attributes → Create attribute. For a business event schema, use its Properties tab under Settings → Events. Choose Evaluated on demand, give it a name and stable key, and describe the answer.

A useful relationship brief is:

Return the Subscription whose externalId equals this Customer's subscriptionId. Return one subscription. If there is no match, return no record.

A useful list brief is:

Return this customer's three most recent completed Orders, matching Order.customerId to Customer.userId, ordered by purchasedAt from newest to oldest.

These examples require the named schemas and fields to exist and contain values. Explain the actual identifiers your source uses; similar names do not create a join automatically. Use @ to reference fields in the prompt where available.

The Generated definition contains a readable description and a badge for the return type. maxinja chooses either a schema target with one or many cardinality, or a JSON result with a defined shape. Review that choice as carefully as the business rule. An email expecting one subscription needs different content from one receiving a list.

Refine the definition if the match key, date window, status filter, order or limit is wrong. Generate the refinement, then save the field. A new prompt alone is not a new saved calculation.

Why you never see the logic

The generated expression stays on maxclicks servers. The app exposes the definition for your review. Validate it with real records: one expected match, one exclusion, and one missing-data case. For a latest or top-N relationship, include a record with several possible matches so you can verify the ordering.

The readable definition explains intent; the returned values establish whether that intent matches the data you actually hold. Use both before sending.

What you can build on it

A record relationship resolves the current record when requested. Changing a company's name changes the value seen on a later lookup; the relationship is not a copied company profile.

Use attribute expansion to select the relationship and any nested fields an email or workflow needs. A one-record relationship with no match yields no record. A many-record relationship yields a list; write an explicit fallback for an empty list.

One place it will not appear

The public Records API does not include evaluated attributes in ordinary record reads or lists. Selecting a field in an email's Data panel configures that email's rendering context; it does not change the public record response.

What it costs and how it behaves at read time

Generating and refining a definition uses AI credits. Reading the saved definition executes data logic rather than asking a model to infer a new answer. That can still involve several lookups, particularly for nested relationships.

Each requested evaluation uses the source records available at that time. Two steps can see different results if records change between them. A fresh calculation cannot compensate for a source that has not synced its latest records.

A many-record relationship returns at most 1,000 records; excess results are truncated with a warning. Ask for a business-sized result such as the latest three orders instead of relying on that cap. Invalid result shapes or missing generated logic can fail the read rather than quietly produce an empty value.

What you cannot break

maxclicks records the schemas, attributes and segments a generated definition references. Those dependencies can block deletion or incompatible changes. Read the reported dependency and update the consuming definition before removing its source.

Refine a definition when its business meaning changes; existing logic is not automatically regenerated from a revised description. Avoid circular relationships such as A requiring B while B requires A. Expansion detects a circular dependency and fails.

Stored or evaluated

Related

• Attribute expansion: select fields and verify real values.
• Attributes: stored types, creation defaults and computed-attribute publication.
• Schemas: define the records and identifiers a relationship needs.
• Segments: apply customer context to an audience decision.