Adobe Journey Optimizer

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

Provide out-of-the-box reporting for individual conditional blocks rendered during personalization within OCM messages. Why is this feature important to you Marketers heavily use Dynamic Content condition blocks to serve tailored experiences (e.g., showing Block A vs. Block B). Without native variant-level reporting, teams are forced to track distinct link URLs or redesign entire use cases as Content Experiments just to see how many users saw which block. How would you like the feature to work The reporting UI should natively break down message exposure metrics by the specific dynamic content variants that were rendered for the audience. Current Behaviour Reporting is strictly at the message or channel level, with no out-of-the-box reporting available for individual conditional blocks rendered during personalization

Update the Campaign Reporting UI to allow filtering by specific run timestamps rather than just aggregating metrics by day. Why is this feature important to you Enterprise orchestrations often run multiple times a day (e.g., every 6 hours). Without instance-level granularity in the UI, stakeholders face massive reporting blindspots and must rely on custom AEP query service backends to properly distinguish performance between multiple runs on the same day. How would you like the feature to work The Batch Instance selector in the reporting UI should permit filtering by precise execution timestamps, not just by the date. Current Behaviour If an orchestrated campaign runs multiple times a day, the OOTB UI only shows aggregated daily metrics because the Batch Instance selector filters by day, not by timestamp

Allow Orchestrated Campaigns to natively evaluate freshly updated table values mid-execution rather than relying on execution-time snapshots. Why is this feature important to you We often need to verify if a user achieved an action (like changing an order status or receiving a previous email) right before sending a subsequent message. Inserting wait periods of several hours just to natively re-query updated datasets severely degrades the real-time nature of orchestrated messaging. How would you like the feature to work Introduce a configuration that forces a live evaluation of specific linked relational datasets mid-canvas before proceeding to the next delivery node. Current Behaviour Because OC relies on a batch-oriented snapshot at execution time, it does not evaluate freshly updated table values mid-execution

Enable OCM to perform a live Unified Profile Service (UPS) lookup to check consent before every email send, rather than relying on a static batch snapshot. Why is this feature important to you Strict compliance with privacy regulations demands that if a user denies consent mid-execution, they are immediately suppressed. Relying on workarounds like injecting wait periods and rebuilding audiences before every single channel send creates incredibly bloated and inefficient workflows. How would you like the feature to work The engine should automatically verify current consent status via a live UPS ping immediately before executing any delivery node, identical to how an AJO Journey operates. Current Behaviour OCM operates on a batch-oriented model using a "snapshot" taken at publication or run time; if a user denies consent while a campaign is mid-execution, they will still receive the scheduled emails

Introduce a runtime profile status to natively block profile re-entry while a user is still actively in-flight within an Orchestrated Campaign. Why is this feature important to you For daily recurring campaigns, architects currently face overlapping, concurrent journeys because profiles are pulled in again before exiting the workflow. Resolving this currently requires maintaining a custom active flag explicitly in the data model and updating it via external systems, which adds unnecessary architectural overhead. How would you like the feature to work OCM should natively expose a runtime profile status (such as "active" or "in-progress") that acts as a built-in mechanism to natively block campaign re-entry while a user is still actively in-flight. Current Behaviour Unlike standard Journeys, OCM does not natively expose a runtime profile status, providing no built-in mechanism to natively block re-entry while a user is still in-flight

Ensure Enrichment activities only expose the specific relational row that matched the initial "Build Audience" criteria rather than bleeding into the entire related-record level. Why is this feature important to you Practitioners need precise downstream personalization. When the system qualifies a profile based on a specific condition (like an order status of "Pending") but exposes all orders associated with that user during enrichment, it necessitates building redundant filtering logic directly inside the Enrichment data setup to prevent personalization errors. How would you like the feature to work The Enrichment step should automatically inherit and restrict the relational data to only the specific row that matched the initial condition in the Build Audience step. Current Behaviour The "Build Audience" step only qualifies the Person ID, and the downstream enrichment step automatically exposes the broader related-record level for that person rather than restricting it to the matched

I have used the experiment feature quiet a lot for the e-mail channel in our different onboarding journey’s (batch audience, sending daily) and recurring sales journeys. However, I have to stop my journeys and duplicated them and then adjust them each time I want to scale a winner, as the great scale the winner feature is not supporting outbound marketing e-mails yet (only api-triggered). There is a huge potential in getting the feature for this type of channel, as I believe this must still be the largest channel for majority of companies? I really hope this can be considered for the roadmap. I’ve eagerly checked the release notes each month since we got to be beta testers of Experimentation Accelerator about a year ago. Bonus: I’ve also just launch a test of the new Experiment feature inside the new Optimize node, to test different journey paths. My test is live now, but also doesn’t look like there a scale the winner feature for this one?Thanks for all the work on experimentations no