Evaluated attributes

Define a customer fact once and use it in an audience, email or journey. An evaluated attribute can find related records or calculate an answer when you need it. You describe the question; maxinja generates the logic; you check the result.

An evaluated attribute has generated logic and a timing rule. This page explains on-demand relationships and calculations. A scheduled event-history definition publishes results in the background and has separate publication and freshness rules. Both appear as evaluated attributes in the app; review their timing before relying on a value.

Example: has this person created a project?

Loopwell wants to contact new users who have not created their first project. Counting projects across the whole account would miss the difference between someone’s own progress and a teammate’s work.

Define Own projects as “Count projects created by this person.” The Loopwell demo records return:

The account is the same. The answer changes because the definition follows the person who created each project. The demo calls this field Project count.

These are verified values from fictional demo records, not customer results.

Before you begin

You need customer and project records with an identifier that links a project to its creator. An account relationship alone cannot answer who created it. Check the source values before generating the definition; maxclicks cannot infer an absent relationship.

Give the field a clear name, such as Own projects, and decide what it should return: a number, one related record or a list. For this count, a customer with no matching projects should return 0; an unavailable or failed calculation is not the same as zero.

Create one

Open Settings → Schemas, choose a schema, then Attributes → Create attribute. Event payload attributes are supplied by the producer; create reusable evaluated context on a contact or object schema. Choose Evaluated attribute under How is the value set?, give it a name and stable key, and describe the answer.

For the Loopwell example, describe the count:

Count Project records created by this User, using the project’s creator relationship. Do not include projects created by other users in the same account. Return a number, or zero if no projects match.

Use your actual schema names and creator identifier. Reference this record’s fields with @ where available. Explain which source keys identify the same person; similar field names do not create a join automatically.

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.

Check the definition against real records

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.

For Own projects, compare a customer with zero projects and one with a known project. Include two people from the same account, as in Maya and Daniel’s case, to catch an account-wide count. Check an absent creator identifier separately.

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

Reuse Own projects wherever the next decision needs this person’s progress:

This reuses the business definition. It does not freeze one answer everywhere: a later request can see newer source records. For a customer whose count has changed, re-check the next decision before sending.

Return a related record or list

A relationship is a question with a record as its answer: “Which account does Maya belong to?” or “Which orders belong to Sarah?” The contact remains the recipient. The returned object supplies facts such as the account plan or order contents.

You store the match keys, then describe how to compare them. The rule can link a contact to objects or one object to other records; matching field names alone do not establish a connection. For example:

• One subscription: “Return the Subscription whose externalId equals this Customer’s subscriptionId. Return no record if there is no match.”
• Recent orders: “Return this customer’s three most recent completed Orders, matching Order.customerId to Customer.userId, newest first by purchasedAt.”

Those examples require the named schemas and identifiers to exist. Review the target record type, one or many cardinality, sorting and limit before using the result.

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.

Update definitions and dependencies

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 scheduled-attribute publication.
• Schemas: define the records and identifiers a relationship needs.
• Segments: apply customer context to an audience decision.