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:

Tab	Purpose
Journey Designer	The canvas itself
Simulation	Test the journey with sample details, without sending anything
All Journeys	Every 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.

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

Triggers

What enrolls a person into the journey. Every journey needs at least one.

Webhook

Fires when your system posts to the journey's generated URL. The panel gives you the URL, an authorization token, and a copyable cURL command, so you can test it before wiring anything up. Declare the request body parameters you intend to send; those become the variables downstream nodes can read.

Scheduler

Fires when a schedule elapses. Pick a schedule mode and a timezone, then fill in what that mode needs:

Mode	Asks for
One time	A single date and time
Every X minutes	An interval from 1 to 59
Every X hours	An interval from 1 to 23
Daily	A time of day
Weekly	A day of week and a time of day
Advanced cron	A cron expression, for example `0 0 9 * * *`

Event Trigger

Fires when a named event arrives from the web tracker or events API. Configure the event name, which must match what you send.

Shopify Trigger

Fires on a store or storefront event. Configure the Shopify store and the event type:

Event	Happens when
Order Created, Order Paid, Order Cancelled	An order changes state in your store
Checkout Started	A shopper begins checking out
Customer Created, Customer Updated	A customer record is added or changed
Product Updated	A product changes
Page View	A shopper loads a page
Exit Intent, Add to Cart, Time on Page, Scroll Depth	A shopper behaves a certain way on your site

Time on Page and Scroll Depth ask for a number: how many seconds, or how far down the page.

Behavioral triggers need a delivery node that fits

The behavioral triggers were designed with storefront popups in mind, and popup delivery is not enabled yet. Until it is, pair these triggers with a delivery node that does exist, such as a Shopify Variant or an email, rather than expecting an overlay.

Abandoned checkout timing

Checkout data does not arrive instantly, and guest checkouts have no email address attached at the moment the checkout is created. Give a recovery journey a wait of at least fifteen minutes after the checkout trigger before the first send, or it will fire on incomplete data.

Meta Lead Trigger

Fires when a Meta Lead Ad form is submitted. Configure the Meta Marketing connector, and optionally narrow to a single page ID and form ID. Leave those blank to accept every form on the account.

HubSpot Trigger

Fires on a HubSpot CRM event. Configure the HubSpot connector and event type, then optionally a property and a property value filter so the journey only starts when that property changes to a value you care about.

Channels

These end a path by sending something. Each one needs its channel connected in the same environment.

Every channel node starts with a connector, which is the account it sends through. If the connector is missing, the node cannot run.

Email

Configure the connector, send mode, to, from, and from name. Send mode decides the rest:

Text mode asks for a subject and body you write inline.
Template mode pulls the subject and body from a SendGrid dynamic template, and you supply the variables that template expects as key and value pairs.

Recipients accept a literal address, a comma-separated list, or a {{variable}} such as {{customer_email}} that resolves per person.

SMS

Configure the SMS or Twilio connector and the message body. Sender ID is optional and overrides the default number.

Push Notification

Configure the push and in-app connector, title, and body. Optional: deep link to open a specific screen, device token to target one device, image URL, and custom data as JSON for your app to read.

Configure the connector, recipient phone, and message type. Template messages are pre-approved and open a session, so they take a template, a template language, and optional template params as a JSON array. Free-form messages take a message body instead.

In-App Message

Configure the connector, contact ID, title, body, and layout. Optional: image URL, CTA label and CTA link, deep link, device token, and a message expiry in hours.

Voice Call

Configure the voice call connector and the TTS message to be spoken. Agent override and phone number override let one node deviate from the connector defaults.

Logic

Rule

Routes the flow true or false. Built in the condition builder over the variables available at that point, so it is the same set the properties panel lists. Conditions can be grouped and nested rather than kept flat.

Wait / Delay

Pauses the journey. Pick a wait mode:

Mode	Asks for
Fixed Duration	A duration amount and a duration unit
Until Time	An absolute until date and time
Until Event	An event to wait for, so the journey holds until it arrives

AI Decision

Classifies with a model and routes on the result. Configure the AI provider connector, model, and prompt, then an output type:

Boolean gives you a true and a false path.
Enum gives you one path per case you define, so you can add and remove cases.

Date Condition

Gates the flow on a date comparison. Configure a timezone and an operator (before, after, or between). Between also asks for an end date and time.

Multivariant Split

Splits traffic across variants A, B, C and beyond. Each variant takes a single-character label. Add and remove variants down to a minimum of two. The node runs in one of two strategies.

Manual, the default. Each variant takes a traffic percent. The last variant is managed for you and marked Auto: it absorbs whatever is left so the total always reaches 100, which is why its field is locked.

MAB, switched on with Enable MAB (Multi-Armed Bandit). Allocation stops being something you set and becomes something the bandit learns. Variant percentages are replaced by auto-allocated, and a MAB Stats panel shows impressions, conversions, and posterior data per variant, refreshing every 30 seconds.

Success goal is the conversion signal the bandit optimizes toward. Until you set one, the bandit stays on an even split and learns nothing. Three kinds:

Goal type	A variant wins when
Reaches a step	Its participants reach a chosen downstream node
Fires an event	A named event arrives within the goal window, matched by visitor identity
Shopify order	A Shopify order lands within the goal window

Event and Shopify goals take a goal window in hours, defaulting to 168 (seven days). Send events to /api/events/trigger carrying the same visitor id.

Pick a goal only some participants reach

A step goal only teaches the bandit when reaching that step is variant-dependent. If every participant funnels through it, such as a shared Checkout both arms lead to, the bandit cannot tell the variants apart and the split stays even. For a purchase, signup, or anything that happens after the journey, use Fires an event or Shopify order instead. The node warns you when it detects this.

Rollout controls how the bandit starts and how it serves:

Starting traffic split is either current, meaning it begins from the manual percentages above and moves only once data justifies it, or even, meaning it begins from an even split and explores all variants equally.
Serve traffic proportionally to the learned split decides delivery. Off is winner-take-all, serving the current best variant. On splits live traffic by the learned allocation. This applies to that node only.

While there is too little data to be confident, the stats panel reports safe mode and falls back to a uniform split. That is the bandit protecting you, not a fault.

Persist Flow Output Path pins a participant to one arm. Tick Keep same variant for same upstream value. With it off, the same person can land in different variants on different runs, which contaminates any result you read.

When on, supply the field to pin against. Xenia takes a fast hash of that field's value and routes on it, so the same value always resolves to the same variant. {{token}} wrapping is stripped, so {{userId}} and userId are equivalent.

Source	Use
Shopify storefront	`payload.visitorId`
Webhook payloads	`body.customer.id`
Known contacts	`userId`

Pin on the same identity the goal matches

For Shopify, pin on payload.visitorId. Event and Shopify goals credit conversions by visitor identity, so pinning on a different field than the goal matches means a participant can be assigned one variant and have their conversion credited elsewhere. Keep both on the visitor id.

Data drivers

Fetch data mid-journey so later nodes can use it.

API Request

Calls any HTTP endpoint. Configure the URL and HTTP method, then authorization:

Auth	Asks for
None	Nothing
Bearer Token	A bearer token
Basic Auth	A username and password
API Key	A key name, key value, and whether it goes in the header or the query

Optionally add headers, body, and query params as JSON, plus a timeout in milliseconds.

Klaviyo Data

Configure the Klaviyo connector and an operation. Depending on it: lookup by to choose how the profile is matched, a Klaviyo list, or an event name with optional event properties as JSON.

Contentful Data

Configure the Contentful connector and select the entries to resolve.

Content Cloud Data

Configure the Content Cloud connector and a content key for the resolve API and SDK. You can also paste entry IDs directly.

GA4 / Warehouse Data

Configure the connector type and connector name, then the data object to read, a read mode, and an optional filter as JSON.

Enrich Customer

Loads the stored Shopify profile, orders, and engagement metrics for the person in the journey. No configuration, since it acts on whoever is in the run.

Check Shopify Order

Checks whether the customer purchased since abandoning checkout, so a recovery send can be suppressed. Configure a fallback lookback in hours, used when the run carries no checkout timestamp to measure from.

Shopify Discount

Adds the customer to a price rule's eligibility list and outputs the coupon code for use in a message. Configure the price rule, discount code, optional code prefix, start date, end or expiry, maximum total uses, and customer eligibility.

Flow control

Parallel

Runs several branches at once. Add and remove branches, then pick a failure mode:

Stop on first error aborts the journey as soon as any branch fails.
Stop only if all fail lets the journey continue while at least one branch succeeds.

Iterate

Loops over each item in a collection. Configure the array to iterate and a batch size.

Merge

Rejoins paths that were split. Configure when this step runs:

Wait for every branch pauses until all incoming paths complete, so every branch's variables are available downstream.
Continue as soon as any one finishes proceeds on the first arrival, which means the slower branches' variables will not be there.

Router

Gives each incoming path its own follow-up. Configure the input lanes and the display, which shows one lane at a time to keep a busy canvas readable.

Integrations

Each of these needs its connector configured in the same environment, and each needs an email field telling it which variable identifies the person.

Audience Lookup

Configure the audience and an operation: CHECK to test membership, or ADD and REMOVE to change it.

Meta Audience Sync

Configure the Meta Marketing connector, audience ID, and operation (ADD or REMOVE). Takes an email field and an optional phone field for matching.

Meta CAPI Event

Sends a server-side conversion event. Configure the connector, event name, and action source. Optional: phone field, currency, value field for the amount, and event source URL.

HubSpot: Update Contact

Configure the HubSpot connector and email field, then the properties to write back.

HubSpot: List Sync

Configure the connector, list ID, operation (ADD or REMOVE), and email field. The list must be a static list.

HubSpot: Create Deal

Configure the connector, email field, deal name, pipeline, and deal stage. Amount is optional.

Responses and composition

Shopify Variant

Shows saved Visual Editor page variants, and ends the path. Configure the Shopify store and the variants to serve. The list is ordered, and you move entries up and down to control precedence when several variants target the same page. See the Shopify Visual Editor.

Webhook Response

Returns a custom HTTP response to the webhook caller, and ends the path. Configure the response status code, response message, and optional response headers as JSON.

This is what lets another system ask Xenia a question and get an answer straight back: it calls the journey, the journey runs, and the response step replies.

Sub-Journey

Runs another journey as a step, so shared logic lives in one place. Start by importing from an existing journey, then set the guards that stop it running away:

Field	Controls
Window duration	How long the sub-journey stays open
Fire "Window expired" when	The condition that takes the expiry output instead
Cooldown between spawns	Minimum gap before the same customer can spawn it again
Maximum spawns per customer	An optional hard ceiling per person

Sub-journeys are guarded, not unlimited

Composition is cycle and depth guarded, so a sub-journey cannot recurse forever. The cooldown and maximum spawn settings are the per-customer half of that protection. Set them deliberately on any event-driven sub-journey.

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.

Only active journeys run

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.

Simulation to test before launch
Journey Manager to move work through review
Journey Library for pre-built starting points