Skip to main content
The Automation Builder lets you turn customer events into email, push, and data workflows without writing the automation definition by hand. A journey starts with an event, follows the connections between steps, and ends when there are no more steps to run or it reaches an end_automation step.

​
Before you begin

Prepare the resources your journey will use:
  • Publish any email or push templates you plan to send.
  • Verify the sending domain used by email steps.
  • Configure a push app before adding push steps.
  • Create any audiences or topics the automation will update.

​
Build a journey

  1. Create an automation and give it a clear name and description.
  2. Choose the event that starts the journey, such as user.created or order.completed.
  3. Add the actions, waits, and conditions the customer should move through.
  4. Connect each step to the next step. Conditions and event waits can lead to different branches.
  5. Save the draft, then validate it before publishing.
For example, an onboarding journey could:
  1. Start when user.created is received.
  2. Send a welcome email.
  3. Wait for user.activated for up to two days.
  4. Send a getting-started push when the event arrives.
  5. Send a reminder email when the wait times out.

​
Configure the trigger

The trigger event name must match the event sent to Sendrealm. You can also add filters when only some occurrences should start the automation. Use correlation when later events must be matched to the same order, checkout, subscription, or other business object. A correlated wait_for_event step should use the same correlation key as the trigger.

​
Choose the right steps

  • Use delay to continue after a fixed amount of time.
  • Use wait_for_event when the next path depends on customer behavior. Configure both the matched and timeout paths.
  • Use condition to branch using contact or event data.
  • Use email and push template steps for messages. These steps reference published templates rather than copying message content into the automation.
  • Use audience, topic, and contact steps to keep customer data and preferences in sync.
  • Use end_automation when you want a branch to finish explicitly.
Give every step a descriptive, stable key. Step keys appear in validation results and run timelines, which makes a journey much easier to troubleshoot.

​
Validate and test

Validation checks that the journey has one trigger, valid connections, reachable steps, no cycles, complete branches, and valid resource references. Fix every validation issue before publishing. Saving a draft does not activate the journey. Use a test run to exercise the current draft without sending messages or changing production data. Test runs let you inject synthetic events and advance virtual time, making it possible to verify event waits, delays, and timeout branches without waiting in real time.

​
Publish and operate

Publishing creates the version used for new production runs. Future edits remain in the draft until you validate and publish again. After publishing, use the Runs page to inspect the path taken by each customer, step status, waits, linked messages, and errors. Pausing prevents new runs from starting; it does not cancel runs already in progress. Resume the automation when it is ready to accept new events again.

​
How it maps to the API

The builder and API use the same automation model:
  • definition: executable trigger, steps, and connections
  • editor_layout: node positions and viewport metadata
Only definition affects execution. editor_layout preserves the visual arrangement for future editing.

​
Best practices

  • Start with one customer outcome and keep each journey focused.
  • Always provide a timeout path for wait_for_event steps.
  • Test both successful and timeout branches before publishing.
  • Review referenced templates, audiences, topics, domains, and push apps when moving a journey between projects.
  • Publish a new version after changing behavior; saving the draft alone does not update production runs.