Build, test and publish customer journeys
Automations run a workflow for an identified contact. A trigger starts the journey; connected steps send messages, wait, make decisions, or update the contact. Published versions are immutable, and each execution keeps the version it entered.
Choose a trigger and audience
Available triggers: contact created, named event, API trigger, segment entry, date, birthday, and schedule. A trigger can restrict
list_ids; an empty selection means all lists, while selected lists must match the contact's primary list.An event belongs to a contact occurrence, not a list. An event-triggered journey first matches the event name and then checks the selected audience and entry conditions. Use names such as
purchase_completed consistently in your application.Build the workflow
- Open Automations and start with a template or blank graph.
- Configure the trigger, purpose, timezone, and entry/re-entry settings.
- Connect a sequence of steps and give each decision outcome a next step.
- Select workspace-owned senders and templates, or write custom channel content.
- Review exit conditions and avoid connecting a loop that could repeatedly message a customer unintentionally.
Use one content source per send action. Template selection shows the template preview; custom selection shows editable content. Smart Channel needs separate configuration for every priority channel.
Simulate before publishing
Test mode simulates messages, webhooks, and contact changes, can skip delays, and does not spend money, send, invoke outbound webhooks, or mutate contacts. Test executions are excluded from production metrics.
Simulation has a boundary: simulated contact updates do not change later conditions; those conditions use the selected contact's real current values. A staging contact and controlled live check are still needed to prove actual provider delivery.
Publishing enables live entry. Review sender, audience, purpose, and content before using Publish; the simulation is not a provider delivery test.
Publish and edit
Publish the reviewed draft to enable the trigger. Saving changes creates a new draft snapshot. Existing executions retain their version and original trigger properties; editing the draft does not rewrite active runs.
The execution screen shows resolved step outputs, available variables, waits, and errors. Use it to distinguish an audience mismatch, a paused run, an unconnected outcome, and a provider failure.
Pause, archive or stop
Pause blocks new entrants. The pause setting chooses whether existing executions hold or continue. Archive holds executions and preserves history. Pending sends may retain wallet reservations while held.
Stop all active executions is the cancellation action when stopping work is intended; review its confirmation. Do not assume archive or pause refunds every pending message.