Attributes

Attributes give your team a shared vocabulary for customer decisions: plan, renewal date, last purchase or spend over the last 30 days. Each belongs to a schema and has a defined value type. The key decision is where its value comes from.

For a renewal campaign, store the renewal date on the Subscription object, use an evaluated relationship on Customer to find that subscription, and use a scheduled evaluated attribute for recent customer activity. One fact belongs on the thing it describes; the relationship makes it usable from the person.

For example, changing a Subscription's stored renewal date changes what a later evaluated lookup reads. It does not itself publish a new activity count or rewrite an email already prepared. Choose the value source before configuring its type.

Add a field to a schema

Open Settings → Schemas, choose a contact or object schema, then open Attributes → Create attribute. For business event schemas, open Settings → Events and the event's Attributes tab.

Choose Stored value or Evaluated attribute under How is the value set?. For a stored field, select its Value type. Give it a Name people will recognize, a Key for templates and integrations, and a Description. Explain units and business meaning in the description: “Monthly subscription amount in EUR, excluding tax” is more useful than “Amount.” maxinja uses this context when generating audiences and logic.

The key stays fixed after creation. Changes to a stored field's value type or accepted values go through setup review, which checks existing values and saved consumers before applying the new rules. It must be unique within the schema and cannot reuse a built-in field. Use a stable name such as renewalDate; changing the display name later does not change references to that key.

Pick the right type

A custom email field does not replace the contact's built-in email identity or sending address. A JSON field does not create a relationship just because it contains an ID. Model those connections explicitly.

Validation applies to writes from the app, API, forms and imports. Read the error for the field that failed, then correct the source or the schema. A field with a fixed option list accepts its configured values, not any similarly worded label.

Decide what happens when a value is missing

The stored-field form asks When a record is created without a value:

AI autofill offers Infer from the record and Follow a prompt. A prompt should specify the intended output and what to do with weak evidence. The resulting value must still pass the field's type validation.

These policies apply when a record is created. They do not fill old records retroactively and do not run on an update that omits or clears the field. An explicitly supplied value takes precedence. An explicit empty value is still checked against whether the field accepts emptiness.

Adding a required stored field to a populated contact or object schema needs an explicit value for existing records. A future creation default does not satisfy that backfill. Use Fill existing empty records, or make the field optional. Event occurrences cannot be backfilled: adding a required event field to recorded history is blocked; keep it optional or create a new event type for the new contract.

Fields maxclicks works out for you

Choose Evaluated attribute under How is the value set? when you need a reusable relationship, answer or scheduled measure. For example: “Find the Subscription whose external ID equals this customer's subscription ID.” Review the generated target, whether it returns one record or many, and its readable definition. See evaluated attributes.

A generated definition has a timing rule as well as a value type. An on-demand relationship runs when selected. An event-history measure publishes a result on its saved schedule. Review the generated timing before saving; a rolling measure is not recomputed for every email.

Scheduled evaluated attributes

Open the destination contact or object schema under Settings → Schemas → Attributes → Create attribute. Choose Evaluated attribute under How is the value set? and describe the event history it should measure. The result belongs to that profile schema; event schemas themselves are not destinations for profile values.

Describe the source, measure, time window and refresh schedule. For example:

For Customer profiles, count PurchaseCompleted events explicitly linked to that customer in the last 30 days. Include only events whose status is completed. Update every hour.

The current calculation supports one event schema as its source, including its configured browser or server collection history, with:

• Count, sum of a numeric property, or the latest property value by occurrence time.
• Typed filters on available properties, including comparisons, presence checks and AND/OR groups.
• An optional grouping property, which produces a JSON array of grouped values.
• A rolling window from 60 seconds to 30 days and an update cadence from one hour to 30 days. If unspecified, generation proposes a 30-day window with hourly updates.

The source must identify the contact or object it describes. A custom property containing an email address or an order ID is not a substitute for the explicit subject link. The calculation does not invent a join through unrelated records. For a more complex relationship, use an evaluated attribute or prepare the required fact in your source system.

Review before creating

Generate the definition, then check its explanation, inferred type, destination schema, event source, filters, window and cadence. The field key identifies the attribute in content and integrations; it is not an authentication token.

For business event schemas, Preview values samples up to five existing profiles. It shows the window's end and No matching value when no qualifying events exist. A preview does not save the attribute or publish a background result. A calculation over collected event history requires setup review for its preview. Follow the reported review path; an unavailable direct preview does not mean no activity exists.

Refine an incorrect definition and generate it again before saving. Typing an instruction alone does not apply it. Count produces an integer, sum produces a decimal, and latest follows the source property's type. Changing an existing scheduled definition requires validation of the replacement result and its dependents through setup review.

Current calculation limits allow up to 10 definitions per workspace and up to 20 grouping values. A preview can also reject a sample that is too large. Narrow the window or grouping when the error asks for it; a preview is a bounded validation step, not an export of the entire audience.

Understand publication and freshness

The Published value panel shows Data through, Last completed and Published results. “Data through” is the end of the measured event window; it is the timestamp to compare with your campaign's decision, rather than the time you opened the record.

Refresh now queues a calculation. It does not synchronously replace the value. Check the published timestamp after the calculation completes.

A valid publication with no matching history for a profile produces an empty value, not zero. No complete publication is unavailable and blocks a decision that requests it. An enabled attribute also blocks a new decision when its publication is past its cadence plus a one-minute grace period. The last publication may remain visible for inspection; visibility does not establish readiness. A paused attribute with a retained publication can use that last result. Write fallbacks for genuinely missing history separately from unavailable or expired calculations.

Broadcast revisions and workflow root runs hold a selected generation for consistent reads; a newer publication does not automatically replace their in-progress context. See expansion freshness before using a current profile preview to explain an older run.

These are read-only calculated fields: imports and API record writes cannot set them. They must be selected through attribute expansion for email and workflow data. A Evaluated attribute threshold trigger can react to published values crossing a configured condition; review that trigger's baseline and transition rules before activating it.

What you can change later, and what you cannot

Open an attribute to change its name, description and supported display settings. The key and choice between stored and evaluated values remain fixed. Stored value types, required rules, option lists, bounds, defaults and evaluated definitions can affect existing data or saved consumers, so saving them starts a setup check.

For a stored field, Existing records makes the conversion explicit:

For example, turning free-text planTier into a fixed option list can expose professional, Pro and pro as different existing values. Map those exact values to pro, inspect the review examples, and check the affected audience before applying. Keeping them unchanged only succeeds if all fit the new option list. Even widening the accepted range needs review because a saved condition or template may assume a narrower domain.

When creating a stored field, Fill existing empty records is a separate explicit backfill. It fills a constant on existing records. The creation-time default still governs future new records; neither option automatically copies a newly selected default into every old record.

A successful save can apply a change after its checks pass. Changes that need a decision appear under the schema's Changes tab. The Changes link at the top of Settings → Events opens workspace-wide history. Inspect invalid values, proposed replacements, affected saved rules and producer checks there. A reviewed proposal is not an applied schema. See Setup changes for checks, producer tests, workflow waiting, application and recovery. Address the reported blockers and use the offered application action only after the review matches your intended meaning.

Some changes prepare data while the current setup stays live; the final switch can pause the workspace. During a pause, refused record writes or producer events need a retry after reopening. Already retained workflow entries are checked separately. Keep the change page open, inspect completion and any resumption warnings, and use Check Apply status after an uncertain application response instead of assuming the change failed.

For scheduled evaluated fields, refine the definition, review the replacement and inspect the next published result after application. These fields must allow empty values and cannot also use a stored-field default or AI autofill. Changing a display name alone does not regenerate the calculation.

Deletion goes through the same dependency checks. Read the named consumers and repair or remove their references before retrying. Integration-managed schemas and attributes are read-only for manual definition changes.

Use a field's value

Use the record and field paths shown in the editor's Data tab. A broadcast's contact key comes from its contact schema; templates and workflows can declare their own data keys. Stored writable fields arrive with the record. Evaluated and scheduled evaluated attributes require expansion.

The public Attributes API describes field definitions. The Records API reads and writes supported stored record data; a plain record response does not include evaluated relationships or published scheduled values. See Liquid for email field paths and fallbacks.