Understanding events

An event records a business moment that can change the next customer action: a completed purchase, an abandoned cart or an expired trial. Declare the facts it carries, then use it to start a relevant journey or inform a customer calculation.

Define the event before anything sends one

For a business occurrence, open Settings → Events → Create event schema. Use a clear name such as PurchaseCompleted, then declare its custom fields in Attributes: amount, currency, order ID and the status your campaign should count.

Have your producer supply a stable eventId, the occurrence time, and a maxclicks contactId or objectId when the event describes a known record. At most one explicit subject is allowed. A custom field containing an email does not replace that subject link.

For browser or server observations, bind a collection source on the same event schema's Collection tab. Select the associated contact or object schema and an optional JSON context attribute. The event's attributes and slug define what this producer sends; there is no separate collection property definition to keep in sync.

Events are added, never edited

An accepted business occurrence keeps the definition and input associated with that acceptance. It is not updated like a contact or order. If a purchase is refunded later, record the refund as a separate occurrence rather than changing the original purchase event.

Preparation can still complete after acceptance. Missing AI-autofill fields can leave an event pending until the values are prepared. Only ready events feed normal business-event queries and downstream event delivery. Erasure of a subject or schema can remove associated history; “immutable” does not mean exempt from deletion.

Make a retry safe

Use one stable eventId for one occurrence and repeat that ID with unchanged input after a network timeout. An identical retry returns the original acceptance receipt with a duplicate marker. Reusing the ID with different input is a conflict.

The original receipt is not a live status report. If it says the event was pending at acceptance, use the event status operation to learn whether preparation is now ready, failed or unresolved. Creating a different ID to retry creates a different occurrence and can create more automation.

Put an event to work

An event on its own is only a note that something happened. It becomes useful when you point automation at it:

• Start a workflow. Add an Event Fired trigger step, choose the event schema, and every matching event starts a run with the event's data in hand. A PurchaseCompleted might start a workflow that waits three days and then asks for a review.
• Call your own systems. A webhook with the Event fired trigger forwards it to a URL you control.

Choose the stream for the decision

Business events and collected observations serve different decisions. A completed purchase can start a journey immediately after it is ready. Product views or feature usage can form a typed collected stream and feed a recurring measure of interest or activity.

A browser source collects anonymous observations. Your authenticated server controls the link to a contact. That link does not grant email consent, and saving a collection definition does not publish a workflow for it.

A scheduled evaluated attribute can count observations over a window and refresh on a cadence. It may be more useful to act when the resulting measure crosses a threshold than to send a message for each observation. See scheduled evaluated attributes.

Record or event?

Ask whether you are describing a thing or a moment. If you would ever change it later, it is a record. If it only makes sense as a one-time signal, it is an event.

The two work together. Sarah remains the Customer contact; Order 184 is the object you keep updating; PurchaseCompleted is the occurrence that can start her thank-you journey. Supply the explicit contact subject when the event should contribute to Sarah's scheduled purchase history, then configure and publish the workflow that acts on it.

Check what actually arrived

Inspect the event library and Logs history for a business schema, then check the individual acceptance/readiness status when diagnosing a missing event. Live in the library means recent activity and a configured trigger, not proof that this occurrence delivered an email.

Next inspect the published trigger, its condition and the workflow run. For a scheduled evaluated attribute, check its published Data through timestamp: refreshing the event list does not refresh the calculation.

Next

Connecting records, or the events reference for sending them from your own code.