Journeys
Multi-step business logic that triggers calls, messages, and API calls from your own data and events
A journey is a separate layer from the voice agent builder — a workflow of steps ("nodes") that runs when something happens: a webhook fires, a schedule ticks, a contact list row matches a condition, an inbound event arrives, or you click Run. Where a voice agent workflow is the conversation graph inside one call, a journey is the business logic around calls — deciding when to call, what to do with the result, and what happens next.
Journeys are stored and executed separately from voice agent workflows (which you build in the Voice Agent Builder). A call node inside a journey is what connects the two — it dials out using one of your existing voice agents.
Journeys were previously called "Automations" in the product. The underlying API still refers to them as automation-workflows — see the Journeys API Reference — but everywhere in the app UI and in these guides, this feature is called Journeys.
How it fits with voice agents#
- 1
Trigger
- 2
Journey nodes
- 3
call node
- 4
Voice Agent Workflow
- 5
Call run + gathered_context
- 6
More journey nodes
- 7
End
A voice agent workflow only knows how to run one conversation. A journey decides when to start that conversation, feeds it context, reacts to how the call went (answered, no answer, voicemail, busy), and can chain further steps afterward — a WhatsApp follow-up, an HTTP call to your CRM, a delayed retry, or a call to a completely different agent based on what happened.
Building blocks#
Every journey is a directed graph of nodes, edited on a canvas in the same style as the voice agent builder:
- A trigger node — exactly one per journey, the entry point. It doesn't do anything on its own; its configuration says when the journey should run.
- Action nodes —
call,message(WhatsApp),http,emit_event,update_contact,load_history,schedule(follow-up) - Flow control nodes —
condition(branching),wait(delay),end
See Journey Nodes & Triggers for what each node type does and the configuration it needs.
Creating a journey#
From Journeys in the dashboard, click New Journey. The AI Copilot walks you through setup:
- Choose One-time (upload a list and dial it once, right now — this is best suited to a single outbound push) or Ongoing (runs automatically on a trigger: schedule, webhook, data change, and so on).
- For an ongoing journey, pick a trigger category — Data Condition, API Events, Schedule, Webhook, Workflow Event, or Manual. See Journey Nodes & Triggers for what each one needs.
- Describe what should happen, step by step, in your own words (for example, "when this fires, call the contact, then if they don't answer send a WhatsApp follow-up"). The copilot turns each step into a configured node on the canvas as you go.
- You land in the canvas builder with the graph the copilot generated. From here you can keep editing manually — add, remove, or reconfigure nodes from the Add New Node panel, grouped into Triggers, Actions, and Flow Control — then Save.
You can also click Import on the Journeys list to upload a previously exported journey as JSON (the same name / description / definition / trigger / context_schema / settings shape returned by the API).
A newly created journey starts in draft status. Set it to active before its trigger will fire — a draft or paused workflow can still be run manually via Test, but real triggers (webhooks, schedules, events) only fire against active workflows.
The builder#
Inside a journey, the editor has three tabs:
| Tab | Purpose |
|---|---|
| Canvas | The node graph — add, connect, and configure nodes |
| Report | Aggregate results across runs |
| Runs | Individual run history for this workflow |
Use Test to run the journey immediately with a custom context, bypassing pause state, allowed-hours restrictions, and queue/concurrency limits — useful for checking a node's configuration without waiting for a real trigger. Test runs are tagged internally so they don't get mixed into your production run history statistics.
Triggers#
Every journey has exactly one trigger, configured on the canvas's trigger node. Lemu supports six trigger types:
| Trigger | Fires when |
|---|---|
| Manual | A user clicks Run (or calls the fire-trigger endpoint) |
| Webhook | An external system POSTs to a unique, auto-generated URL |
| Schedule | A cron expression matches (with timezone support) |
| Data Condition | A row in a contact list matches a condition — polled continuously, one run per unique row |
API Events (contact_event) | Your app posts an inbound event (e.g. cart_added) that matches this trigger's event type, optionally after a delay and with a cancellation event |
| Workflow Event | Another journey's emit_event node fires a matching event name |
Full configuration fields for each are in Journey Nodes & Triggers.
Runs#
Every time a trigger fires (or you click Test/Execute), Lemu creates a run — the execution record for that pass through the graph. A run moves through these states:
| State | Meaning |
|---|---|
queued | The trigger reserved this run; no node has executed yet |
pending | Dispatched to a worker; about to start |
running | Actively executing nodes |
waiting | Suspended on an async node — an outbound call in progress, or an async wait |
completed | Reached an end node successfully |
failed | A node failed and the run could not continue |
cancelled | Manually stopped |
You can see all runs for the organization on Journeys → Runs, or per-workflow on the journey's own Runs tab. Each run's history shows every node that executed, its input/output, and timing — useful for debugging why a particular row or event didn't produce the outcome you expected.
The Journeys list table shows a Runs (24h) count and how many of those are still active — a quick way to spot a workflow that's stuck or hasn't fired recently.
Pacing and safety controls#
Each journey has its own settings, independent of its trigger:
| Setting | Purpose |
|---|---|
| Allowed hours / days | Restrict which hours and days of the week the workflow is allowed to run (with timezone) |
| Max concurrent runs | Cap how many runs of this workflow can be active at once, bounded by your organization's overall concurrent call limit |
These apply to real (non-test) runs — a Test run bypasses pause state, allowed hours, and queueing so you can validate a workflow immediately.
Calling a voice agent from a journey#
The call node is the bridge to your voice agents. It:
- Places an outbound call through one of your existing, active voice agents
- Optionally waits for the call to finish before continuing (
wait_for_completion), suspending the run (statewaiting) until the call ends - Passes selected context variables from the journey into the call as
initial_context, with optional name aliasing if the journey's field names don't match the agent's prompt variables - Can pull the agent's extracted variables back into the journey's context afterward
- Routes to a different next step depending on how the call ended — completed, busy, no answer, voicemail, or failed
This is what makes journeys useful on top of voice agents: the journey decides which contacts to call and when, the voice agent handles the actual conversation, and the journey picks up again with the result — sending a WhatsApp confirmation, updating a CRM via http, or scheduling a follow-up call in N days.