Skip to main content

How it works

Steps are the building blocks of Automation workflows. They define the actions that will be executed when the Automation runs. The following steps are available:

Step properties

Every step in an automation has the following base properties:
string
required
A unique identifier for the step. Used in connection definitions to connect steps.
string
required
The type of step. Possible values:
  • trigger
  • send_email
  • delay
  • wait_for_event
  • condition
  • contact_update
  • contact_delete
  • add_to_segment
object
required
The configuration object for the step. The shape depends on the step type.
Below is a list of all the possible step types and their configurations.

trigger

The trigger step starts the automation when a matching event is received.
string
required
The name of the event that triggers the automation.

send_email

Sends an email using a template.
object
required
The published template to send. Provide id and optionally variables.
string
The sender email address.If provided, this value will override the template’s default value.
string
The email subject line.If provided, this value will override the template’s default value.
string
Reply-to email address.If provided, this value will override the template’s default value.

delay

Pauses execution for a specified duration.
string
required
The delay duration in natural language (e.g. "1 hour", "3 days"). Maximum: 30 days.
Example

wait_for_event

Pauses execution until a specific event is received or a timeout is reached.
string
required
The name of the event to wait for.
string
The maximum time to wait before timing out (e.g. "3 days", "1 hour"). Maximum: 30 days.
object
An optional rule object to filter incoming events.
Example

condition

Branches the workflow based on rules. Condition configs can be a single rule or a logical group (and/or) of rules.
string
required
The type of condition node. Possible values:
  • rule
  • and
  • or
For rule type:
string
required
The field to evaluate. Must use the event. or contact. namespace prefix (e.g., event.amount, contact.email).
string
required
The comparison operator. Possible values:
  • eq: equals
  • neq: not equals
  • gt: greater than
  • gte: greater than or equal to
  • lt: less than
  • lte: less than or equal to
  • contains: contains a given value
  • starts_with: starts with a given value
  • ends_with: ends with a given value
  • exists: field exists
  • is_empty: field is empty
string | number | boolean | null
The value to compare against. Not required for exists and is_empty operators.
For and / or types:
object[]
required
An array of nested condition config objects. Must contain at least one item.
Single rule example:
Use and or or to combine multiple rules into a single branch:

contact_update

Updates a contact’s fields. Each field value can be either a hardcoded value or a dynamic variable reference using the { var: '...' } syntax. Variable references use dot-notation with one of these scopes:
  • event.*: references a field from the triggering event payload (e.g., event.firstName).
  • contact.*: references a field from the current contact (e.g., contact.last_name, contact.properties.company).
string | object
The contact’s first name. Accepts a hardcoded string or a variable reference.
string | object
The contact’s last name. Accepts a hardcoded string or a variable reference.
boolean | object
The contact’s unsubscribed status. Accepts a boolean or a variable reference.
object
A map of custom contact properties to update. Keys correspond to your Contact Custom Properties. Each value can be a hardcoded value (string, number, boolean) or a variable reference.
Example

contact_delete

Deletes the contact from the audience. This step does not require any configuration fields. Pass an empty object {} as the config.
Example

add_to_segment

Adds the contact to a segment.
string
required
The ID of the segment to add the contact to.
Example