Multi-step orchestrated journey
This guide provides a comprehensive implementation blueprint for building multi-step orchestrated journeys using Adobe Journey Optimizer (AJO) and Real-Time Customer Data Platform (RT-CDP). It is designed for solution architects, marketing technologists, and implementation engineers who need to orchestrate branching, multi-touch customer journeys that deliver multiple messages over time.
It presents all viable implementation options, decision considerations at every configuration point, and links to Adobe Experience League documentation. Use this guide to plan, configure, and validate your multi-step journey implementation.
Use case overview
Multi-step orchestrated journeys address business scenarios where a single message is insufficient to achieve the desired customer outcome. Instead of a one-time send, the journey guides each profile through a sequence of touchpoints – emails, SMS messages, push notifications, or in-app messages – spaced over days or weeks, with branching logic that adapts the path based on profile attributes, behavioral signals, or event data.
These journeys are the most complex campaign pattern in AJO. They combine audience-based or event-based entry with a canvas of action nodes (messages), condition nodes (branching logic), wait nodes (time delays), and exit criteria (conversion events or timeouts). Each profile progresses through the journey independently, at their own pace, receiving contextually relevant content at each step.
This pattern subsumes the simpler patterns – batch outbound message activation for single-send campaigns and event-triggered messaging for single-event responses. Use this pattern when the use case requires nurturing a profile through multiple interactions over time.
Key business objectives
The following business objectives are supported by this use case pattern.
Improve customer retention
Keep existing customers engaged and renewing through value-driven experiences and ongoing relationship nurturing.
KPIs: Retention, Customer Lifetime Value, Engagement
Learn more about improving customer retention
Improve customer onboarding
Accelerate time-to-value for new customers with streamlined, personalized welcome experiences and activation journeys.
KPIs: Engagement, Retention, Conversion Rates
Learn more about improving customer onboarding
Re-engage dormant customers
Win back inactive or lapsed customers with targeted reactivation campaigns based on behavioral signals.
KPIs: Engagement, Retention, Conversion Rates
Learn more about improving customer retention
Recover abandoned carts and journeys
Re-engage users who dropped off during purchase, application, or enrollment flows with timely, personalized follow-ups.
KPIs: Conversion Rates, Incremental Revenue, Engagement
Learn more about recovering abandoned carts and journeys
Example tactical use cases
The following scenarios illustrate common applications of the multi-step orchestrated journey pattern.
- Customer onboarding series – Welcome email, followed by feature education, then an activation prompt over the first 14 days after registration
- Re-engagement drip campaign – A reminder email, then an incentive offer, then a final notice for lapsed customers over 3 weeks
- Loyalty milestone journey – Tier upgrade notification, followed by an exclusive offer, then a renewal reminder as the membership anniversary approaches
- Win-back sequence – “We miss you” email, then a discount offer via email, then a final SMS reminder for lapsed purchasers
- Product adoption journey – Trial welcome, usage tips, then an upgrade prompt as the trial period progresses
- Subscription renewal sequence – 30-day notice, 7-day reminder, then an expiry-day message for upcoming subscription renewals
- Post-purchase nurture – Thank-you email, how-to-use guide, cross-sell recommendation, then a review request over 30 days after purchase
Key performance indicators
Use the following KPIs to measure the effectiveness of your multi-step orchestrated journey implementation.
Use case pattern
Multi-Step Orchestrated Journey
Guide a profile through a branching, multi-touch journey with waits, conditions, and multiple message actions over time.
Function chain: Audience Evaluation > Journey Execution (multi-node) > Condition Branching > Message Delivery (xN) > Exit Criteria > Reporting
Applications
The following applications are used to implement this use case pattern.
- Adobe Journey Optimizer (AJO) – Journey orchestration engine, message authoring, channel configuration, content experimentation, frequency and conflict management, and reporting
- Adobe Real-Time Customer Data Platform (RT-CDP) – Audience evaluation and definition for journey entry audiences, profile data for personalization and condition branching
- Adobe Experience Platform (AEP) – Profile store, identity service, event data ingestion, and foundational data infrastructure
Foundational functions
The following foundational capabilities must be in place for this use case pattern. For each function, the status indicates whether it is typically required, assumed to be pre-configured, or not applicable.
Supporting functions
The following capabilities augment this use case pattern but are not required for core execution.
Application functions
This plan exercises the following functions from the Application Function Catalog. Functions are mapped to implementation phases rather than numbered steps.
Journey Optimizer (AJO)
Real-Time CDP (RT-CDP)
Prerequisites
Complete the following prerequisites before beginning the implementation.
- [ ] AJO sandbox is provisioned with journey creation and publish permissions
- [ ] At least one channel surface (email, SMS, or push) is configured and active
- [ ] Profile schema includes attributes needed for condition branching and personalization
- [ ] Experience Event schema is configured for conversion events used in exit criteria
- [ ] Event streaming is active for real-time events used in exit criteria or event-triggered entry
- [ ] Identity namespaces and merge policies are configured for cross-channel profile resolution
- [ ] Content assets (images, copy, CTAs) are prepared for each message touchpoint
- [ ] Entry audience is defined and evaluated (for audience-read journeys)
- [ ] Triggering event schema is configured (for event-triggered journeys)
- [ ] Test profiles are available for journey test mode validation
- [ ] Suppression list is reviewed and up to date for all channels used
Implementation options
Review the following options to determine the best approach for your multi-step orchestrated journey.
Option A: Audience-read orchestrated journey
Best for: Time-based nurture sequences where a known audience enters the journey and progresses through scheduled touchpoints – onboarding series, renewal sequences, re-engagement drips, loyalty milestone journeys.
How it works:
An audience is read at journey entry, either as a one-time read or on a recurring schedule. All qualifying profiles enter the journey simultaneously and then progress through the canvas at their own pace, governed by wait durations and condition evaluations. Each profile’s path through the journey is independent – some may take the “engaged” branch while others take the “not engaged” branch based on their behavior or attributes.
The audience is evaluated at the time the Read Audience activity executes. For recurring journeys, the audience is re-evaluated on each recurrence, and new qualifying profiles enter the journey while profiles already in the journey continue their path. This approach provides predictable entry timing and is well-suited for scheduled lifecycle programs.
Key considerations:
- Audience must be defined and evaluated before journey activation
- Recurring read allows new qualifiers to enter on each cycle
- Profiles in the journey are not re-read; only new qualifiers enter on subsequent reads
- Wait steps have a minimum duration of 1 hour for audience-read journeys
Advantages:
- Predictable entry timing aligned with business schedules
- Supports large audience volumes (up to 20,000 profiles per second default throttle)
- Simple to test and monitor with known audience populations
- Can be scheduled for recurring entry (daily, weekly, monthly)
Limitations:
- Entry is batch-based, not real-time – profiles enter at the scheduled read time, not when they qualify
- Not suitable for behavior-initiated sequences that require immediate response
- Audience changes between reads are not reflected for profiles already in the journey
Experience League:
Option B: Event-triggered orchestrated journey
Best for: Behavior-initiated sequences where a real-time event starts the journey – cart abandonment escalation, post-purchase nurture, milestone-triggered loyalty journey, trial activation sequences.
How it works:
A unitary event (for example, a purchase, cart abandonment, form submission, or app install) triggers journey entry for individual profiles in real time. When the event is received, the profile enters the journey and then progresses through the sequence of touchpoints with conditions, waits, and branching. This approach combines the immediacy of event-triggered messaging with the multi-step orchestration of a full journey.
The triggering event must be configured as a journey event with its schema and conditions defined. The journey listens for the event continuously and enters profiles one at a time as events arrive. Subsequent journey nodes can evaluate the profile’s response to determine which branch to follow.
Key considerations:
- Requires real-time event streaming to be active
- Event schema and conditions must be precisely configured to avoid false triggers
- Re-entry rules are critical – determine whether a profile can re-enter if the event fires again
- Supports up to 5,000 events per second per sandbox
Advantages:
- Real-time entry based on customer behavior – highly contextual
- Each profile enters independently when the event occurs, not on a schedule
- Natural fit for behavioral response sequences (cart abandonment, post-purchase)
- Can combine with profile data for personalized branching after entry
Limitations:
- Requires streaming event infrastructure to be in place
- Higher complexity in event schema configuration and testing
- Each event enters one profile – not suitable for bulk audience activation
- Debugging requires tracing individual profile journeys
Experience League:
Option C: Multi-channel orchestrated journey
Best for: Cross-channel sequences that use different channels at each touchpoint – email then SMS then push escalation, or email plus in-app complementary messaging. Can use either audience-read or event-triggered entry.
How it works:
This option extends Option A or Option B by incorporating multiple messaging channels within the same journey. Each action node in the journey can target a different channel (email, SMS, push, in-app, or web), requiring a separate channel surface for each. The journey designer selects the appropriate channel at each step, enabling escalation patterns (for example, email first, then SMS if no engagement) or complementary patterns (for example, email with in-app reinforcement).
Cross-channel journeys require channel surfaces for each channel used and must account for channel-specific personalization, character limits, and opt-in requirements. Condition nodes can check engagement with previous messages (for example, “opened email?” as a branch condition) to determine the next channel.
Key considerations:
- Requires active channel surfaces for each channel used in the journey
- Each channel has different personalization capabilities and content constraints
- Consent must be verified per channel – a profile may be opted in for email but not SMS
- Channel-specific frequency caps should be configured to prevent over-messaging across channels
Advantages:
- Maximizes reach by engaging profiles across their preferred channels
- Enables escalation strategies for non-responsive profiles
- Supports complementary messaging across channels for reinforcement
- Most sophisticated customer experience possible
Limitations:
- Highest implementation complexity – requires configuration for each channel
- Content must be authored for each channel at each touchpoint
- Consent and frequency management become more complex across channels
- Testing requires validation across all channel surfaces
Experience League:
Option comparison
The following table compares the three implementation options across key criteria.
Choose the right option
Use the following decision flow to select the right implementation approach:
-
Is the journey initiated by a customer behavior or event? If yes, choose Option B (Event-Triggered). If the journey is initiated by a scheduled audience read, choose Option A (Audience-Read).
-
Does the journey use multiple messaging channels (for example, email AND SMS)? If yes, apply Option C (Multi-Channel) on top of your entry method choice (A or B). If the journey uses a single channel throughout, Option A or B alone is sufficient.
-
Do you need to escalate to a different channel based on engagement? If yes, choose Option C with condition nodes that check engagement with previous messages and branch to alternate channels.
-
Is the audience known in advance and processed on a schedule? If yes, choose Option A. If profiles should enter the journey the moment they perform an action, choose Option B.
Implementation phases
The following phases walk through the end-to-end implementation of a multi-step orchestrated journey.
Phase 1: Set up channels and prepare audiences
Application functions: AJO: Channel Configuration, RT-CDP: Audience Evaluation
Before designing the journey, all channel surfaces must be active and the entry audience (for Option A) must be defined and evaluated. This phase ensures the infrastructure is ready for message delivery.
Decide on channel type for each touchpoint
Which messaging channels will the journey use at each touchpoint?
Decide on audience evaluation method (Option A)
How quickly must profiles qualify for the entry audience?
Decide on subdomain delegation method (email channel)
How should the email sending subdomain be delegated to Adobe?
UI navigation
- Channel surfaces: Administration > Channels > Channel surfaces > Create surface
- Subdomains: Administration > Channels > Subdomains
- SMS configuration: Administration > Channels > SMS configuration
- Push configuration: Administration > Channels > Push notification settings
- Audiences: Customer > Audiences > Create audience > Build rule
Key configuration details
- Verify IP pool warmup status for email – new IP pools require a gradual warmup plan over 2-4 weeks
- For SMS, configure provider credentials and verify sender number registration
- For push, upload APNs certificates and FCM server keys
- Define the entry audience using Segment Builder with segment rules covering the target population
- Include suppression rules in the audience definition (exclude recently converted, globally unsubscribed)
Where options diverge
For Option A (Audience-Read):
Define and evaluate the entry audience. Confirm the audience has a non-zero population. Determine whether the journey will use a one-time audience read or recurring read schedule.
For Option B (Event-Triggered):
Verify that the triggering event schema is configured and that events are streaming into the platform. No pre-defined audience is required – profiles enter individually upon event receipt.
For Option C (Multi-Channel):
Configure channel surfaces for EACH channel used in the journey (email, SMS, push, in-app). Verify consent status per channel for the target population.
Experience League documentation
Phase 2: Create message content
Application function: AJO: Message Authoring
Author the message content for each touchpoint in the journey. Each message may have different content, personalization depth, and channel. This phase creates all the deliverable content that journey action nodes will reference.
Decide on content approach
Should each message start from a template, be designed from scratch, or import HTML?
Decide on personalization depth
How much personalization should each message include?
Decide on fragment strategy
Should shared content blocks (headers, footers, legal text) be created as reusable fragments?
UI navigation
- Content Management > Content Templates > Browse
- Email Designer (within campaign or journey action)
- Content Management > Fragments > Create fragment
Key configuration details
- Author content for EACH message action in the journey – a 4-step journey may require 4 separate message designs
- Use personalization expressions referencing XDM profile paths (for example,
{{profile.person.name.firstName}}) - Configure dynamic content blocks for segment-specific variations
- Preview each message with test profiles to verify personalization rendering
- Send proofs to internal stakeholders for content review
- For SMS, respect character limits (160 characters for standard GSM encoding)
- For push, configure title, body, image, and deep link/URL action
Experience League documentation
Phase 3: Design and activate the journey
Application function: AJO: Journey Orchestration
Design the multi-step journey canvas including the entry node, action nodes (messages), condition nodes (branching), wait nodes (time delays), and exit criteria. Then test with test profiles and publish.
Decide on entry type
How should profiles enter the journey?
Decide on re-entrance policy
Can a profile re-enter the journey after completing or exiting?
Decide on wait durations between touchpoints
How long should the journey wait between each message?
Decide on branching conditions
What conditions determine which path a profile takes?
Decide on exit criteria
What event or condition causes a profile to exit the journey early?
Decide on journey timeout
What is the maximum duration a profile can remain in the journey?
UI navigation
- Create journey: Journeys > Create Journey
- Journey properties: Journey canvas > Properties panel
- Entry node: Journey canvas > Drag “Read Audience” or event activity
- Action nodes: Journey canvas > Drag channel action (email, SMS, push)
- Condition nodes: Journey canvas > Drag “Condition” activity
- Wait nodes: Journey canvas > Drag “Wait” activity
- Exit criteria: Journey properties > Exit criteria > Configure
- Test mode: Journey canvas > Test mode toggle
- Publish: Journey canvas > Publish
Key configuration details
- Name the journey with a clear, descriptive convention (for example, “Onboarding_Series_Email_v1”)
- Set the journey timezone for consistent wait step processing
- Configure each action node with the appropriate channel surface and link to authored message content
- Every branch must terminate with an End activity
- Configure re-entry rules appropriate to the use case
- Use test mode with test profiles to simulate the full journey path before publishing
- Verify that test profiles traverse expected paths and receive correct messages
Where options diverge
For Option A (Audience-Read):
- Drag the “Read Audience” activity as the entry node
- Select the target audience defined in Phase 1
- Optionally configure a recurring read schedule (daily, weekly)
- Configure the read rate throttle if downstream system load is a concern
For Option B (Event-Triggered):
- Drag the triggering event as the entry node
- Configure the event schema and entry conditions
- Set re-entry rules carefully to avoid duplicate entries from repeated events
For Option C (Multi-Channel):
- Use the entry method from Option A or B
- At each action node, select the appropriate channel surface for that touchpoint
- Add condition nodes between channels to check engagement (for example, “Did the profile open the email?”) and route to alternate channels
Experience League documentation
Phase 4: Configure governance and optimization
Application functions: AJO: Frequency & Business Rules, AJO: Conflict & Priority Management, AJO: Content Experimentation, RT-CDP: Consent & Governance Enforcement
Apply frequency caps to prevent over-messaging, assign priority scores for conflict resolution with other active communications, optionally configure A/B tests within journey messages, and verify consent enforcement.
Decide on frequency cap configuration
Should journey messages respect global frequency caps?
Decide on priority score assignment
How should this journey rank relative to other active campaigns and journeys?
Decide on content experimentation
Should any journey message include an A/B or multivariate test?
UI navigation
- Frequency rules: Administration > Business rules > Create rule
- Priority scores: Journey properties > Priority score
- Conflict detection: Administration > Business rules > Conflict & Priority
- Content experiment: Journey canvas > Select message action > Content experiment toggle
- Consent policies: Privacy > Policies > Consent policies
Key configuration details
- Set channel-specific frequency caps (for example, max 3 emails/week, max 1 SMS/day, max 2 push/day)
- Assign a priority score to the journey (0-100) that reflects its business importance relative to other active communications
- Review the conflict detection panel to identify any overlapping campaigns or journeys
- If running a content experiment, define treatment variants, set traffic allocation, choose the success metric (opens, clicks, or conversions), and set the confidence threshold (typically 95%)
- Verify that consent enforcement is active for each channel used in the journey
Experience League documentation
Phase 5: Configure reporting and monitoring
Application functions: AJO: Reporting & Performance Analysis, Monitoring & Observability, Reporting & Analysis
Monitor journey execution during and after activation, review per-step delivery and engagement metrics, configure alerts for journey processing failures, and optionally build CJA workspace analysis for deep funnel and fallout visualization.
Decide on reporting method
Which reporting tools are needed for this journey?
Decide on alert configuration
What journey failures should trigger alerts?
UI navigation
- Journey live report: Journeys > Select journey > Live report
- Journey all time report: Journeys > Select journey > All time report
- Alerts: Alerts > Alert rules > Subscribe
- CJA workspace: Projects > Create new project
Key configuration details
-
Access the live report during journey execution to monitor profile entries, exits, and per-step delivery metrics in real time
-
After journey completion (or after sufficient data accumulates), review the All Time report for comprehensive analysis
-
Configure platform alerts for journey processing failures and delivery issues
-
For CJA analysis, ensure the CJA connection includes AJO experience event datasets (Message Feedback, Email Tracking, Journey Step Events)
-
Build a CJA Workspace with:
- Funnel visualization showing profile counts at each journey step
- Fallout visualization to identify drop-off points
- Step conversion rate calculations
- Time-to-conversion analysis
- Channel-level engagement breakdown (for multi-channel journeys)
Experience League documentation
Implementation considerations
Review the following guardrails, pitfalls, best practices, and trade-offs before and during your implementation.
Guardrails and limits
- Maximum of 500 live journeys per sandbox – Journey Optimizer guardrails
- Maximum journey duration is 91 days (global timeout) – profiles still in the journey at timeout are automatically exited
- Maximum of 50 activities per journey canvas
- Read Audience journeys process up to 20,000 profiles per second (default throttle)
- Unitary event journeys support up to 5,000 events per second per sandbox
- Wait steps have a minimum duration of 1 hour for audience-read journeys
- Journey re-entrance cooldown minimum is 5 minutes
- Maximum of 10 channel surfaces per channel type per sandbox
- Maximum email size of 100 KB recommended for optimal deliverability
- Maximum of 30 content fragments per message
- Maximum of 10 content experiment treatments (variants) per experiment
- Maximum of 10 capping configurations per sandbox
- Maximum of 4,000 segment definitions per sandbox
Common pitfalls
- Publishing without testing: Always use test mode with test profiles to validate the complete journey path before publishing. Verify that profiles traverse expected branches, wait steps advance correctly, and messages render properly.
- Missing end activities on branches: Every journey branch must terminate with an End activity. The journey will fail to publish if any branch is left without a termination node.
- Overly broad entry conditions: A loosely defined entry audience or event condition can flood the journey with unintended profiles. Refine entry criteria with specific attribute checks and suppression rules.
- Ignoring re-entry rules: For event-triggered journeys, profiles may fire the triggering event multiple times. Without proper re-entry configuration (deny re-entry or cooldown period), profiles can accumulate in the journey, causing duplicate messages.
- Wait step timezone confusion: Wait durations are processed in UTC. Set the journey timezone explicitly in journey properties to ensure wait steps advance at the expected local time.
- Editing a live journey: Live journeys cannot be edited directly. To make changes, duplicate the journey, modify the copy, stop the original, and publish the new version. Plan journey versioning before going live.
- No exit criteria defined: Without exit criteria, profiles who convert mid-journey will continue receiving subsequent messages – potentially irrelevant or contradictory. Always configure exit criteria for conversion events.
- Channel consent misalignment: A profile may be opted in for email but not SMS. Multi-channel journeys must respect per-channel consent. Verify consent fields are populated and enforced at each channel surface.
Best practices
- Start simple, iterate: Begin with a linear 2-3 step journey before adding complex branching. Validate the core flow works before layering in conditions and channels.
- Use descriptive naming conventions: Name journey nodes, conditions, and wait steps clearly (for example, “Wait_3_Days_After_Welcome” rather than “Wait 1”). This makes test mode debugging and report interpretation much easier.
- Configure exit criteria early: Define the conversion event as an exit criteria before designing the journey paths. This ensures profiles who convert are removed from the journey regardless of which step they are on.
- Set meaningful wait durations: Base wait durations on customer behavior data – time between typical interactions, expected response windows, and channel-appropriate cadence (for example, 2-3 days between emails, 1 week between SMS).
- Use condition nodes to check engagement: After a message action, add a condition to check whether the profile engaged (opened, clicked). Route engaged profiles to one path and non-engaged profiles to an escalation or alternate channel path.
- Leverage computed attributes for branching: Use computed attributes such as engagement scores, purchase frequency, or days since last activity to make branching decisions data-driven rather than arbitrary.
- Monitor and optimize iteratively: Review journey reports weekly during the initial run. Identify drop-off points, adjust wait durations, refine conditions, and optimize message content based on per-step performance data.
- Version your journeys: When making changes, duplicate the journey to create a new version. Maintain a log of version changes for audit and optimization tracking.
Trade-off decisions
The following trade-offs should be evaluated in the context of your specific business requirements.
Audience-read entry vs. event-triggered entry
Audience-read entry provides predictable, batch-based processing that is easier to manage and test. Event-triggered entry provides real-time responsiveness that is more contextually relevant but requires streaming infrastructure and more careful re-entry management.
- Audience-Read favors: Predictability, large-volume processing, scheduled lifecycle programs, simpler testing
- Event-Triggered favors: Real-time relevance, behavioral context, individual profile pacing, immediate response to customer actions
- Recommendation: Use audience-read for planned lifecycle programs (onboarding, renewal) where timing is business-driven. Use event-triggered for behavioral response sequences (cart abandonment, post-purchase) where timing is customer-driven.
Single channel vs. multi-channel journey
Single-channel journeys are simpler to implement, test, and manage. Multi-channel journeys provide broader reach and escalation capabilities but increase complexity in content creation, consent management, and frequency governance.
- Single channel favors: Faster implementation, simpler consent management, lower content production effort, easier debugging
- Multi-channel favors: Higher engagement potential, channel escalation for non-responsive profiles, more comprehensive customer experience
- Recommendation: Start with a single-channel journey and validate the flow and business impact before expanding to multi-channel. Add channels incrementally where engagement data shows the primary channel is not reaching the audience effectively.
Journey complexity vs. manageability
A highly branched journey with many conditions and paths can address more scenarios but becomes harder to test, debug, and optimize. A simpler journey with fewer branches is easier to manage but may deliver a less personalized experience.
- Complex journeys favor: Granular personalization, segment-specific paths, comprehensive scenario coverage
- Simpler journeys favor: Faster deployment, easier testing, clearer reporting, lower maintenance burden
- Recommendation: Limit journeys to 3-5 major branches and 15-25 activities. If the logic requires more complexity, consider splitting into multiple journeys with cross-journey coordination rather than a single monolithic journey.
Frequency cap strictness vs. journey completion
Strict frequency caps protect against over-messaging but may suppress journey messages, causing profiles to skip steps and reducing journey completion rates. Lenient caps ensure journey messages are delivered but risk channel fatigue.
- Strict caps favor: Customer experience protection, reduced unsubscribe rates, brand trust
- Lenient caps favor: Journey completion rates, full message sequence delivery, marketing program effectiveness
- Recommendation: Assign higher priority scores to critical journey messages (onboarding, renewal) so they take precedence over promotional campaigns when caps are reached. Reserve “exempt from capping” for truly essential communications only.
Related documentation
The following resources provide additional detail on the capabilities used in this implementation.