Marcel Szimonisz
Updated: May 2, 2026
4 minutes read
24

How to Create Journeys in Adobe Journey Optimizer

The fastest way to create journeys in Adobe Journey Optimizer is to pick an entry (event or audience), build the path with actions, waits, and conditions on the canvas, then validate and publish. This matters because it turns triggers and audiences into coordinated, cross-channel messages without custom glue code. In practice, the work breaks down into three steps: define how people enter, orchestrate the flow, and set guardrails for eligibility and re-entry.

Table of Contents

Decide how the journey starts: event or audience

A journey can start from an event or from an audience and then move profiles through actions, waits, and decisions, as outlined in the journeys overview.

Event-triggered journeys – when and how

Use event-based journeys when timing is everything: transactional confirmations, password resets, cart/browse abandon, or service notifications. The event payload typically carries the context you need to personalize and branch (e.g., product ID, cart value, store location). In practice, what trips teams up is identity linking: if the event’s identity namespace does not match the profile’s primary identifiers, the action cannot resolve personalization. A common issue is filtering on profile attributes that may not be updated yet at event time. When you need immediate gating, prefer conditions built from the event payload fields, then fall back to profile checks later in the path.

Event streams can produce duplicate or near-duplicate payloads. Guard against repeats by checking a unique event key or timestamp window before sending. If the same person can trigger the event multiple times, decide whether to allow re-entry and for how long to suppress repeats. When in doubt, add a short wait and a condition that confirms the desired state has not changed (e.g., “still no purchase” before sending a reminder).

Audience-based journeys – when and how

Audience journeys shine for scheduled or phased communications: onboarding series, lifecycle nudges, or campaigns targeting a qualifying segment. What typically happens is that audience membership is evaluated on a schedule, then eligible profiles enter in batches. Because profiles can join or leave segments over time, be explicit about re-entry expectations. If you only want a person once, combine entry rules with an early exit condition (e.g., “if has already received welcome, end”). If you plan a multi-step nurture, design waits around realistic engagement windows rather than arbitrary delays.

Build the journey on the canvas step by step

On the canvas, you add an entry, stitch conditions and waits, drop in channel actions, and then validate and publish, which the journey creation workflow illustrates.

Step 1 – Configure the entry

Event entry: Select the event, map identities, and expose key payload fields to your conditions. Name the node clearly so downstream logic is readable.
Audience entry: Choose the audience, confirm the evaluation schedule, and document the intended re-entry behavior in the journey description for future maintainers.

Step 2 – Orchestrate with decisions and waits

Conditions: Start with simple, high-signal checks. In practice, event payload checks are more deterministic immediately after entry; profile checks are better a bit later after the system has updated state.
Waits: Use them intentionally. Short waits debounce noisy triggers; longer waits shape a cadence. Avoid chaining many small waits when a single “wait until condition” is clearer. Always provide a default path if a condition might never be met.
Splits: Keep branch count low. Deeply nested logic is hard to test and often hides edge cases.

Step 3 – Add actions and close paths

Channel actions: Configure templates, personalization, and any channel prerequisites. A common issue is missing consent or subscription flags at send time, so include an eligibility check before high-value sends.
End nodes: Close every branch deliberately. Ending early is better than letting a person idle in a limbo path.

Data and identity guardrails that prevent sends

Identity mapping must be unambiguous. If your event uses a device-based ID but your email action requires an email identity, add an early branch to handle the device path separately or enrich the profile upstream.
Personalization fields should be resilient. Where possible, reference event fields for immediate content and profile attributes for persistent traits. If a field is optional, provide a fallback string or branch away from the action.
Eligibility flags matter more than content. A common issue is that contacts fail channel checks at send time (e.g., opted out). Build a pre-send condition that exits gracefully instead of failing silently.

Orchestration behaviors that trip teams up

Re-entry control: Event journeys will naturally re-trigger; audience journeys can re-qualify on subsequent evaluations. Use a suppression window or a “has progressed past step X” flag to avoid repeats.
Infinite waits: “Wait until” with no maximum duration stalls cohorts indefinitely. Add a time cap and a fallback path.
Racing conditions: If you check for “no purchase” immediately after a cart event, you may catch orders that are still processing. A short backoff plus a re-check usually improves accuracy.
Over-branching: Every additional path multiplies test cases. If branches differ only slightly, consider parameterizing a shared action rather than duplicating logic.

Test and publish without surprises

Dry run the logic with real profiles. In practice, the biggest gaps surface when the live payload doesn’t match what the canvas conditions expect. Validate identifiers, payload shapes, and null handling.
Test negative paths on purpose. Ensure exits fire when eligibility fails and that no one is left waiting indefinitely.
Version with intent. Treat each publish as immutable. When you need to change logic, create a new version, note what changed in the description, and sunset the old one only after confirming traffic has drained.

Real-world journey patterns to model

Abandoned cart rescue: Event entry on cart update, short wait, condition check for purchase, then send push or email. Add a 24-hour cap and a suppression window to prevent repeats.
Double opt-in: Event entry on signup, send confirmation, wait for verify event or timeout, then either welcome or expire. Keep the timeout realistic for mobile users with intermittent connectivity.
Onboarding series: Audience entry on “new customer,” then a spaced sequence with behavior-based branching (e.g., skip tips email if app opened 3 times). Use exits to stop the series once the activation goal is hit.