Journeys

Journeys are how you automate follow-ups in Leadara: a welcome SMS after signup, a reminder when someone abandons their cart, a win-back offer for quiet customers. You design the flow on a canvas, connect your templates, and turn the journey Active when validation passes.

Journeys in 3 minutesTutorial · 2–4 min · Not recorded yet

Script to read

Hey — in this walkthrough I want to show you journeys in Leadara. I'm in the dashboard under Journeys, and the fastest way to start is Create from template, so let me do that.

I'll pick Abandoned cart recovery. See how the canvas comes pre-wired? There's a trigger on "added to cart", then a wait-for-event node that watches for a purchase, and two paths out of it: On Trigger if they buy, and On Timeout if they don't. That timeout path is where the reminder SMS lives. This is the whole point — if the customer purchases, they leave the journey automatically and never get the nudge. Nobody likes "you left something in your cart" after they've already paid.

Let me click the trigger node. Notice the event name field auto-suggests events we've actually seen from your store, and if I type something we've never received it warns me — because journeys match the event name exactly, so a typo means it silently never fires.

Now I'll point the SMS node at our cart reminder template. If I forget that, or leave the provider on "test", Leadara tells me before I activate instead of failing silently later. When everything's green I hit Activate in the sidebar. And see that little dot on Save? That just means I have unsaved changes — Leadara won't let me wander off and lose them.

That's the loop: template → connect templates → activate. You can pause anytime without losing your draft.

Ready-made flows

Start from New journey → Create from template for proven, pre-wired flows:

• Welcome — greet new customers a minute after they sign up.
• Abandoned cart recovery — remind people who added to cart but didn't buy; purchasers exit automatically.
• Browse abandonment — nudge people who viewed a product but didn't add it to cart.
• Post-purchase follow-up — check in by email a couple of days after a purchase.
• Win-back — re-engage a segment of customers who've gone quiet.

Templates copy their nodes into a fresh draft you can edit freely. Swap in your own message templates and audiences, then activate.

Triggering on the exact event

Event-triggered journeys fire when your store sends a matching event — and the match is exact and case-sensitive. purchase_completed and Purchase Completed are different events, so the safest habit is to use the same names everywhere you track.

To make that easy, the event field on a trigger:

• Auto-suggests events Leadara has actually received from your workspace.
• Warns you when the name you typed has never been seen — usually a sign of a typo or a name your site doesn't send.

Recommended names for an online store (send these from your site or app): signed_up, product_viewed, product_added_to_cart, checkout_started, purchase_completed. Put the variable bits (product, total, order id) in the event's properties, not in the name.

Waiting for the next step

Two kinds of wait let you pace a journey:

• Wait — pause for a fixed time (e.g. 1 day) before the next step.
• Wait for event — pause until a specific event happens, with a timeout. This node has two exits: On Trigger (the event arrived) and On Timeout (it didn't in time). Abandoned cart uses this: wait for purchase_completed; if it comes, they leave happy; if the timer runs out, send the reminder.

Leaving a journey automatically

Set exit rules on a journey so people drop out the moment a goal happens — for example, exit on purchase_completed. As soon as that event arrives, the person is removed and any pending waits are cancelled, so they won't get a later step that no longer makes sense.

By default, someone who's already moving through a journey won't be enrolled a second time, so repeated triggers don't pile up duplicate messages. Use entry rules to go further — limit re-entry, add a cooldown, or cap total entries.

Troubleshooting with run history

When someone should have received a message but didn't, open Run history from the journey sidebar (or Journeys on their user profile). Each run shows a step-by-step trace: which nodes ran, which failed, and where the journey paused on a wait.

Green Finished means the step completed. Failed shows the error (for example missing phone number or provider rejection). Waiting means the person is paused on a wait node. Exited means they reached an Exit step or matched an exit rule.

For SMS issues, also check SMS logs under Integrations — run history tells you whether the journey reached the SMS step; SMS logs tell you whether the provider accepted the send. Once the carrier confirms delivery, the log updates on its own from Sent/Pending to Delivered (or Failed) — no refresh needed.

SMS & email prerequisites

SMS and email steps need a phone or email on the person's profile before the step runs. Leadara refreshes the profile at send time, but if identify never included contact info, the step is skipped.

• Run history shows explicit failures such as "SMS skipped: no phone on profile" with the fields that were checked.
• Recommended pattern: trigger on identify (after traits are saved), or add an If step that checks phone/email before the message step.
• identify before logged_in on the same page load — track does not carry traits. See Integrate Leadara for session restore on app boot.

Exit steps

People are marked completed automatically when they reach the end of a branch — the last step, or a decision whose matched side has nothing wired after it. As soon as that happens they're released from the journey and can be enrolled again on the next trigger, so you don't need an Exit step just to "finish" a flow.

An Exit step is only needed when you want to record a "journey exited" event or attach a custom exit reason at that point — handy for reporting on why people left. You can still add one at the end of any branch; the editor shows a gentle reminder when a journey sends messages without one, but it's optional.

How activation works

Before a journey goes Active, Leadara checks that it's complete:

• at least one trigger, with the trigger configured (an event name, a form, or — for a win-back — the audience segment chosen);
• every message step linked to a real template (or chat + text);
• a heads-up warning if a message step is still on the test provider, which doesn't send real messages.

Fix anything flagged in the validation panel, Save, then Activate. Paused journeys keep their design; activating again runs the same checks.

Tips

• The Save button shows a dot when you have unsaved changes, and Leadara warns you before you leave the page with edits pending.
• Win-back and other segment-triggered journeys refresh their audience automatically about once an hour, enrolling new members who match (and skipping anyone already in the flow or recently messaged).
• Test with a manual trigger and a small segment before turning on event-based entry at scale.
• For Persian SMS or email, preview the template in its own screen first, then select it on the journey node.

SMS templates in the journey editor

When you configure an SMS step, you can manage the message without leaving the canvas. Pick an existing template, create a new one, or edit the name, recipient, and body right in the step panel — the phone preview updates as you type. Save writes your changes back to the workspace template.

Stuck on wording? Give the template a clear name like Welcome or Abandoned cart, then click the ✨ generate icon next to the message field and the AI writes a first-draft message for you based on that name — in Persian or English, matching your dashboard language. It's a starting point: tweak it, drop in variables, and save.

Each template shows how many journeys and SMS steps use it. Click the usage line to jump to those journeys. For richer editing (longer copy, extra review), open Advanced editor to the full template screen in a new tab.

The same usage count appears on SMS templates in the sidebar, so you can see at a glance which messages are shared across multiple journeys before you edit or delete one.

When a run fails

Open Run history on any active journey to see each person's path step by step. Failed runs are highlighted in red with the error message (for example, a web push when the visitor never subscribed).

If a run fails, Leadara releases the enrollment automatically so the same person can enter again on the next trigger. When someone is still marked Still enrolled on an older failed run, use Release user so the next event can enroll them, or Retry failed step to run that step again after you fix the issue (push opt-in, SMS template, and so on). Retry from start re-runs the first action after the trigger — useful when you want the whole flow to fire again without waiting for another event.

Retry failed step re-executes that step and anything wired after it. It does not replay earlier steps, so use it when the failure was on a specific message — not when you need to re-run a wait or branch from the middle of the canvas.

Next steps

Open Segments to define who should enter, or check Events to see what your site is already sending into Leadara.