Adobe Journey Optimizer

I get an error in the Journey canvas about missing opt out link in the email body. Se attached image. This is not correct - since there is a opt out link present in a Footer fragment in the same template. The opt out link i coded in the fragment, and are present in the same way with the same ID-s that is needed for the link to work. But for some reason this manually coded link is not recognized as a out out link when AJO checks the code/template. Se picture of the code with the link. It would be nice if manually placed code also could be recognized when it is actually the same code that AJO is creating. This is an unnecessary error message that cases a lot of confusion.     

If you've ever launched a large-scale campaign and watched your call center buckle under a flood of responses — or worse, seen your email deliverability tank because ISPs flagged you for sending too much too fast — wave sending in Adobe Journey Optimizer (AJO) is the feature you need to know about.In this post, I'll walk through what wave sending is, when to use it, and how to configure it effectively for real-world scenarios.What Is Wave Sending?Wave sending lets you split a single campaign's audience into multiple batches (called "waves") and deliver them on a staggered schedule. Instead of blasting your entire audience at once, you control the pace — sending in 2 to 10 waves, each with its own size and timing.This applies to all outbound actions in AJO: Email, SMS, Push, and Direct Mail. Why Should You Care?Three words: control, reputation, and capacity.1. Protect Your Sender ReputationISPs watch your sending patterns closely. A sudden spike in volume from a domain or IP can trigger

Hi! for clients (even sometimes for us) is confusing to see this numbers in AJO journey canvas:It would be great if somewhere in node card mention which numbers corresponds to previous execution (for example, yesterday) and which ones to actual execution. Regards.

We would like to submit an enhancement request for the Journey list UI in Adobe Journey Optimizer.At the moment, the available filters in the journey list do not provide enough granularity to efficiently manage and analyze journeys at scale. We would like to request two additional filters: A filter by schedule type, so journeys can be filtered by cadence such as daily, weekly, monthly, once, and similar scheduling options. A filter to identify which journeys are included in the active journeys metric, so users can easily distinguish journeys that count toward that metric from those that do not. This second filter is especially important because not all journeys with a Closed status continue to count toward the active journeys metric. It would be very helpful to have a clear way to see which journeys are still contributing to that count.Having these filters would make the Journey list much easier to use for reporting, operational monitoring, and cleanup tasks, and would improve visibi

Description Ensure that standard enumerated field values (such as Loyalty Tier or Subscription Status) populate as selectable dropdown menus within the OCM Audience Builder rather than requiring manual string entry. Why is this feature important to you Forcing stakeholders to manually type exact string values from memory introduces a massive risk for human error. A simple typo or accidental trailing space causes the query to fail silently and return zero profiles. To prevent this teams are forced to maintain external data dictionaries or have architects pre build standardized audiences which adds administrative overhead and severely impacts the usability of the OCM canvas for everyday campaign operators. How would you like the feature to work When a user clicks on an attribute with predefined values in the OCM segment builder the UI should immediately present a dropdown menu of the available enumerated values identical to the standard AEP Segment Builder experience. Current Behaviour T

Description Introduce the IP warming plan activation toggle natively within the Orchestrated Campaign Module (OCM) email configuration screen to match the functionality currently available in standard AJO Campaigns. Why is this feature important to you When migrating to Adobe Journey Optimizer and standing up a brand new instance systematically warming IPs is a foundational deliverability requirement. The absence of this feature in OCM forces architects to use complex workarounds like exporting OCM audiences into the AEP Audience Portal and wrapping them in segment definitions just to safely throttle email volume in a standard scheduled AJO campaign. This completely disrupts the unified orchestration workflow and adds unnecessary build time. How would you like the feature to work Include the standard IP warming plan activation toggle directly within the Email action configuration of the OCM canvas allowing the system to natively handle safe message throttling without forcing practition

A few months ago I built a Post-Purchase journey in Adobe Journey Optimizer that sent a personalised follow-up email based on what the customer bought. The journey had three branches — one each for Electronics, Sports, and HomeDecor — all tested, validated, and live.Then the business expanded into two new product categories: Grocery and Fashion. I updated the journey to add the two new branches and needed to validate them before re-publishing.  The Problem with Test Mode To validate the Grocery and Fashion branches in Test Mode, I needed two new AEP test profiles — one with a Grocery purchase, one with a Fashion purchase. Creating new profiles in AEP is straightforward, but it takes time for them to reflect and become available for testing. I could not just create them and start immediately.With a deadline to re-publish the updated journey, waiting for two new profiles to propagate was time I did not have. Simulation Mode: New Users in Seconds I switched to Simulation Mode instead. I c

The Monday morning that never ends Picture this: it's Monday, and Priya, a journey orchestration lead at a retail brand, has three journeys on her plate. A loyalty re-engagement flow. A trial-to-paid conversion path. A seasonal promotion for a new product line.Each journey needs the same opening move: read the audience, run an eligibility filter, and drop anyone who doesn't qualify. Priya has built that logic at least a dozen times. She knows it by heart. She also knows that if she copies it from an old journey, she'll spend the next hour untangling node references, fixing namespace mismatches, and wondering whether this version matches the one her colleague Marcus built last month.By Tuesday, she's still wiring up the same three nodes. Again.This is the quiet tax of journey building — not the creative work of designing a great customer experience, but the repetitive work of rebuilding logic your team already trusts. Journey Fragments exist to eliminate that tax. What if your best jour

Modern customer journeys rarely stay inside one system. They depend on loyalty platforms, billing engines, CRM tools, fulfilment services, and partner APIs. When one of those integrations fails, the reason behind the failure matters just as much as the failure itself.A temporary outage may need a retry. A duplicate request may need no action at all. A suspended account may require customer service intervention. But until now, custom actions in Adobe Journey Optimizer could detect that a call failed without giving journeys access to the structured error details many APIs already returned.AJO 26.1 changes that with Error Response Payload Support for custom actions. What's New: Error Response Payload Support Custom actions have long supported success response mapping. When an API call succeeds, you can define the response structure, parse the body, and use those fields later in the journey.Previously, error handling worked differently. If a custom action returned a 4xx or 5xx response, AJ

Simulation Mode lets you test draft journeys using Simulated Users — AJO-native temporary profiles that are fast to create, reusable across journeys, and completely separate from AEP test profiles. If you have read the getting-started guide, you have seen how Simulation Mode works for a single journey with a branching condition. This post goes one level deeper: two journeys running in sequence, sharing a single simulated user, where Journey 2 writes profile attributes that Journey 1's condition reads.The use case is credit decisioning. Journey 2 fires on a credit decision event and writes the outcome and the decline reason to the simulated user's profile using an Update Profile node. Journey 1 fires on a product campaign trigger, waits 2 hours, then reads those profile attributes to route the customer to an approved onboarding email or a personalised declined email that renders the specific reason inline.The goal is to prove — with green lines in the Results tab — that the correct emai

m

Allow the selection of Email channel configurations in the OCM UI even if they contain more than one target dimension. Why is this feature important to you Enterprise setups often utilize configurations with a target plus secondary dimensions. Forcing architects to change their design and create a dedicated channel setup specifically for OC adds administrative overhead and fragments channel governance. How would you like the feature to work The OCM UI should gracefully handle and permit the use of channel configurations that include multiple target dimensions without causing canvas failures. Current Behaviour Orchestrated Campaigns require a channel configuration with exactly one target dimension, and configurations with a secondary dimension fail in the campaign canvas

Simulation Mode lets you test draft journeys with Simulated Users—AJO-native test profiles that are quick to create, easy to reuse, and separate from AEP test profiles. This guide walks you from access setup through your first end-to-end run. GETTING ACCESSRequest your admin to grant the right permissions in Access control. Permissions can take a few minutes to appear on your account after they are saved.Journeys resourceRequest one of these high-level permissions on the Journeys resource:Approve And Publish Journeys Publish Journeys Simulate JourneysTo run simulations, Simulate Journeys is the permission you need. The publish-related permissions are listed because some orgs bundle journey testing with publish roles.Simulated Users resourceAlso request access to the Simulated Users resource:Manage Simulated Users View Simulated UsersFor a full quick-start, ask for both Manage and View on Simulated Users, plus Simulate Journeys on Journeys.Note for adminsUse Administration → Permissions

Description -Whenever an offer with status "Approved" has passed its offer end date, the offer is no longer available to customers but it still keeps the status "Approved". This can cause confusing for the AJO user since it's not clear whether the offer is available to customers or not. Why is this feature important to you -We mainly use offers as a way to communicate with our customers and we find it confusing and prone to mistakes when at first glance seeing an offer with status "Approved" but then also have to check the offer end date. We would also like to filter on "Approved" offers where the end date is passed or not. How would you like the feature to work -We would like to have a new offer status introduced called "Finished". The criteria for this status would be that any "Approved" offer that has passed its offer end date will change status to "Finished".

Description Allow practitioners to directly access and evaluate relational table data within the targeting rules of the AJO Orchestrated Campaign Module (OCM) Email Action, rather than restricting access exclusively to the Real-Time Customer Profile (UPS) store. Why is this feature important to you Creating audiences purely as a workaround to access relational attributes clutters the system and adds unnecessary overhead. Practitioners need to leverage relational data directly for efficient email targeting without building redundant intermediary audiences to evaluate disconnected custom lookups. How would you like the feature to work The targeting rules configuration UI within OCM Email Actions should expose linked relational XDM classes alongside UPS attributes, enabling direct rule evaluation natively based on relational data. Current Behaviour Dynamic content targeting rules within the AJO OCM Email Action strictly support the Real-Time Customer Profile (UPS) store; relational table

Increase the architectural limit that restricts orchestrated campaigns to a maximum of 10 inline message activities. Why is this feature important to you Complex, multi-touch orchestration often requires significantly more than 10 total touches. Forcing architects to split their logic across multiple disconnected orchestrated campaigns fractures the customer journey and vastly complicates reporting. How would you like the feature to work Scale the backend architecture to support a substantially higher limit of inline campaigns (messaging actions) on a single orchestration canvas without triggering 6017-500 errors. Current Behaviour OCM imposes a strict hard limit of 10 inline message activities per orchestrated campaign, returning a cryptic "OCM error 6017-500" if exceeded

 Description Expand the date preset dropdown within the builder to include future-relative windows (e.g., "within the next 90 days"). Why is this feature important to you Many marketing use cases rely on anticipating events, such as an order status expiring or a subscription renewing in the near future. Relying on Data Distiller or custom PQL conditions to pre-calculate these dates is an unnecessary hurdle for a standard segmentation requirement. How would you like the feature to work Add standard future-looking presets to the date selection dropdown alongside the existing lookback windows. Current Behaviour The date preset dropdown in the builder focuses exclusively on lookback windows (e.g., "in the last N days") and lacks future date presets

Description Fix the backend missing link-key field generation bug that causes orchestration joins to fail when adding Message Feedback attributes during the Enrichment step. Why is this feature important to you Leveraging message feedback data is fundamental to orchestration. Having to build reverse join workarounds by querying the dataset within the Build Audience step just to avoid database errors is highly unintuitive for practitioners. How would you like the feature to work Users should be able to seamlessly select and join message feedback dataset attributes directly within standard Enrichment activities without triggering failure states. Current Behaviour Adding Message Feedback attributes to an Enrichment step causes the campaign to fail with a database (ODBC) error due to a missing link-key field generation during orchestration joins

Description Ensure the "Source" field in the template interface accurately distinguishes between natively created AJO templates and those synced from external integrations (like Knack). Why is this feature important to you When external integrations feed templates into the system, labeling them all identically as native creates organizational confusion, forcing teams to rely on rigid naming prefixes and dedicated folders to find the right assets. How would you like the feature to work The system should automatically flag the true origin source in the template list UI rather than defaulting externally synced templates to the native source name. Current Behaviour The "Source" field in the template interface cannot be relied upon to distinguish between templates originating in external integrations (like Knack) versus those created directly in AJO, as the UI lists the source as "AJO" for both

Description Allow the UI to gracefully handle the deletion of a "Fork" activity without requiring the manual removal of all subsequent downstream transitions first. Why is this feature important to you Campaign iteration should be fluid. Painstakingly deleting every downstream node just to remove a single fork creates extreme friction and wastes practitioner time during the active build phase. How would you like the feature to work The UI should allow users to delete a fork and automatically sever the downstream transitions, rather than blocking the deletion entirely. Current Behaviour The UI will not let you delete a "Fork" activity if subsequent activities are attached, requiring you to painstakingly delete all transitions following the fork first

Increase the architectural limit that restricts orchestrated campaigns to a maximum of 10 inline message activities. Why is this feature important to you Complex, multi-touch orchestration often requires significantly more than 10 total touches. Forcing architects to split their logic across multiple disconnected orchestrated campaigns fractures the customer journey and vastly complicates reporting. How would you like the feature to work Scale the backend architecture to support a substantially higher limit of inline campaigns (messaging actions) on a single orchestration canvas without triggering 6017-500 errors. Current Behaviour OCM imposes a strict hard limit of 10 inline message activities per orchestrated campaign, returning a cryptic "OCM error 6017-500" if exceeded

Ensure the batchInstanceID is reliably populated across all runs within the ajo_message_feedback_event_dataset. Why is this feature important to you Accurate correlation of message events is essential for campaign analysis. Having to string together messageExecutionID, messageID, and correlationID because the batch instance ID is missing creates brittle and unnecessarily complex reporting queries. How would you like the feature to work The system should guarantee the generation and inclusion of the batchInstanceID for all batch executions across all campaign runs. Current Behaviour When querying the ajo_message_feedback_event_dataset for tracking, the batchInstanceID is sometimes completely empty and is not guaranteed across all campaigns

Expose the exact profile counts transferring between discrete nodes in a system dataset or backend table. Why is this feature important to you While the UI displays profile counts, data engineers and architects need programmatic access to this transition data to validate complex campaigns and feed external observability dashboards. How would you like the feature to work Implement a step event table for OCM (similar to what exists for AJO) that logs the exact profile counts moving between specific activities on the daily basis. Current Behaviour There is no system dataset or backend table exposed to the end user that provides the exact profile count transferring between two discrete node activities on a daily basis

Provide a navigation path or UI link from the Audience UI back to the specific definition or source Orchestrated Campaign that generated it. Why is this feature important to you Robust governance requires understanding exactly how an audience was built. Relying solely on strict naming conventions or external documentation to keep track of audience definitions leads to platform clutter and an inability to trace back the origin of a flat profile list. How would you like the feature to work Audiences generated by OCM should retain metadata linking them back to the source campaign, allowing users to view the logic that created them directly from the Audience portal. Current Behaviour OCM saves audiences purely as flat lists of profiles and currently provides no navigation path back to the definition or source campaign from the Audience UI

Introduce a Dry run or message-skipping feature within the Test Mode for OCM workflows. Why is this feature important to you Validating multi-step workflows is impossible when Test Mode halts progression at the first message activity. Deleting and re-adding nodes just to test downstream flow logic introduces unnecessary friction and risk into the build phase. How would you like the feature to work Similar to the "Dry run" feature in AJO, practitioners should be able to simulate the full progression of a workflow without being halted by or actually triggering the sending of an email node. Current Behaviour When using Test Mode, you cannot test the progression of a workflow past the first message activity without actually skipping the sending emails note