XeniaXenia Docs

Journey Orchestrator

PreviousNext

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.

The canvas

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:

TabPurpose
Journey DesignerThe canvas itself
SimulationTest the journey with sample details, without sending anything
All JourneysEvery journey in the workspace, badged with approved and rejected counts

Build with AI

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:

  • It only plans against the palette you actually have. Nodes whose connector is not configured are not offered, so it cannot design a journey you cannot run.
  • It authors branch rules over the same facts the manual condition builder exposes, so a rule the agent wrote is a rule you can open and edit.

While an AI turn is running, structural edits are locked so the canvas and the agent's plan cannot diverge mid-turn.

Variables

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.

Node reference

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.

CategoryWhat its nodes do
TriggersPut a customer into the journey. Every journey starts with one.
ChannelsReach the customer: email, SMS, push, WhatsApp, in-app.
Data DriversFetch facts about the customer mid-journey, so later nodes can decide on them.
LogicSplit the flow, test a condition, or let time pass.
ResponsesEnd the journey by answering the thing that started it.
Flow ControlShape the flow itself: fan out, loop, or bring paths back together.
IntegrationsWrite to an outside system: a CRM, an ad audience, a Xenia audience.
CompositionRun another journey inside this one.

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.

Reusing configuration

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.

Briefing

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.

Lifecycle

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.

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.

Next