The visual builder where journeys are designed, the AI panel that builds with you, and how a journey moves from draft to live.
The Journey Orchestrator is the canvas. You drag nodes from the palette, connect them, configure each one, and the result is a journey: a flow a real customer moves through, one step at a time.
Nodes are dragged from the palette on the left. Selecting a node opens its properties panel, where you configure it and see the variables it makes available to everything downstream.
The builder has three tabs:
The right-hand Build with AI panel is a designer agent that edits the canvas with you. Describe the journey you want and it plans the nodes, adds them, wires them, and fills in configuration.
Two things make its output usable rather than decorative:
While an AI turn is running, structural edits are locked so the canvas and the agent's plan cannot diverge mid-turn.
Every node publishes variables that downstream nodes can use. A trigger publishes
what it received, a data driver publishes what it fetched, and a channel node
consumes them as {{token}} placeholders in copy, recipients, and URLs.
The properties panel lists what is available at that point in the flow, which is also what the AI writer receives when you draft content from a node. If a variable is not listed at a node, nothing upstream of it produces that value on that path.
Nodes are grouped into eight categories, and every one of them is documented in the Node Reference: what it takes, what it publishes, and when it is the wrong choice.
A node can be in the product and still be missing from your palette: most of them are withheld until the connector they run through exists in this workspace and environment, a few need another node on the canvas first, and workspaces billed through Shopify see a narrowed palette. The reference marks which applies to each node.
Any node's configuration can be saved to the Node Library and reused. In the properties panel, pick a saved instance for that node type and its fields are filled in.
Each journey carries a briefing: the plain language statement of what it does and who it targets. It is required before a journey can go to review, because it is what reviewers read to judge risk. Write it for a colleague who has not seen the canvas.
A journey is a draft while you build it, goes to review when you submit it, becomes approved when someone signs it off, is published when it goes live, and is stopped if you pause it.
Triggers invoke a journey only when its status is active. A draft journey in Production accepts nothing, which is the usual explanation for a webhook that works locally and appears dead in production.
Editing a live journey is allowed, and Xenia warns you when you do. Changes take effect only after republishing, so the running version is whatever was published last.