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

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

Description:We need a feature to filter out automatic email open events that are not caused by recipients or users. This would enable more accurate reporting and evaluation of email campaign performance.Why is this feature important to you:Filtering out non-human interactions is essential for providing accurate open rate metrics, ensuring campaign performance insights reflect genuine user engagement. Additionally, identifying and including non-human interactions (e.g., automatic opens by Apple Mail Privacy Protection - MPP) would help evaluate email address activity and inactivity more effectively.How would you like the feature to work:The feature should detect and exclude automatic opens caused by non-human actions, such as MPP or similar mechanisms, from standard open rate calculations. Simultaneously, it should log and make these automatic opens identifiable for separate reporting purposes, allowing for better analysis of email address activity patterns.Current Behaviour:Currently,

Currently, buyer group role creation in AJO B2B relies on exact-match or limited matching logic for job titles and attributes. This creates constraints when mapping real-world data, where job titles are often inconsistent, varied, or unstandardized.Introducing a “contains” logic would significantly improve flexibility and accuracy in buyer group definition. It would allow roles to dynamically capture a broader and more realistic set of relevant contacts (e.g., capturing variations like “Sr. Director of Radiology,” “Radiology Director,” or “Director, Imaging Services” under a single word - contains “radiology”).This enhancement would:Improve coverage and completeness of buying groups by reducing missed matches Reduce manual effort and dependency on exhaustive title mapping Increase scalability across regions and datasets with inconsistent naming conventions Enable more accurate downstream activation (e.g., LinkedIn, email targeting)Overall, adding “contains” logic will make buyer group

Hi Team, Below are the details :  Detailed Use CaseThere are multiple scenarios in which source data for batch campaigns or journeys is delayed. In such situations, we are required to manually start, stop, pause, or resume all related journeys and campaigns. This significantly increases operational overhead.Once the data issue is resolved, the same set of journeys and campaigns must be manually resumed, meaning the effort is duplicated for every data disruption. As a result, each data failure forces us to perform the same manual operational task twice, which is both inefficient and error-prone.Business JustificationProviding API-level capabilities to start, pause, stop, and resume journeys or campaigns would enable full automation of this process. This would lead to substantial reductions in manual effort and operational burden, while also minimizing the risk of human error.When handled manually, it is very easy to accidentally miss a journey or campaign, which can directly impact reve

Use case: We would like to target customers on below qualified dates and be suppressed if they don’t meet qualified date. So, looking for the solutions to manage dynamic qualified date in the journey if possible. 2 days before 1st Friday of each month e.g. Apr 1, 2026 1st Friday of each month e.g. Apr 3, 2026 1 month after 1st Friday (on 1st Friday only) e.g. May 1, 2026 2 months after 1st Friday (on 1st Friday only) e.g. Jun 5, 2026 3 months after 1st Friday (on 1st Friday only) e.g. Jul 3, 2026

In Adobe Orchestrated Campaign (OCM) Provide functional significance to the "Enable for Segmentation" toggle present on relational schemas. Why is this feature important to you UI elements that have no backend functionality create confusion for data architects and marketers during implementation, leading to unpredictable behaviors and wasted configuration effort. How would you like the feature to work If the toggle is present, it should actively allow the fields within that relational schema to be leveraged in the standard AEP segment builder. If this is not technically viable, the toggle should be removed from the UI to prevent confusion. Current Behaviour The “Enable for Segmentation” toggle on relational schemas has no current significance

Enable Adobe Journey Optimizer (AJO) Journeys to natively query and consume data residing in relational tables. Why is this feature important to you Siloing relational data strictly to Orchestrated Campaigns creates a disjointed architecture. Real-time journeys often need contextual data (like store inventory or loyalty tier lookups) that is best suited for relational storage. How would you like the feature to work Allow AJO journey conditions and personalization syntax to securely reference and pull data from relational schemas linked to the primary profile. Current Behaviour Relational tables are designed for OC only and cannot be directly consumed by AJO Journeys

In Adobe Orchestrated Campaign (OCM) Introduce a native, automated feature to clone XDM profiles into relational stores without dual-ingestion or Query Service workarounds. Why is this feature important to you Architectural simplicity reduces technical debt and maintenance costs. Forcing data engineers to ingest data twice or build scheduled Query Service scripts just to populate relational tables is an inefficient use of platform resources. How would you like the feature to work Provide a UI-driven toggle or standard data prep mapping function that allows specific XDM profile attributes to automatically sync or "clone" into designated relational schemas upon ingestion. Current Behaviour There is no free auto clone feature for xdm profiles into relational stores; data must be ingested twice or derived via Query Service

In Adobe Orchestrated Campaign (OCM) Enhance the test profile creation wizard to include functional hooks for updating or populating relational tables via CSV upload. Why is this feature important to you Robust QA requires highly specific, multi-dimensional test data. The inability to inject test data directly into relational tables hinders our ability to thoroughly validate complex orchestration workflows that rely on those data structures. How would you like the feature to work The test profile wizard should support a CSV template upload that maps test identifiers not only to XDM profile attributes but directly to custom fields within linked relational schemas. Current Behaviour The test profile creation wizard lacks placeholders or functional hooks to update or populate corresponding test data within relational tables via CSV upload  

 In Adobe Orchestrated Campaign (OCM) Update the standard AEP Profile UI to display relational store attributes and cross-table relationships. Why is this feature important to you A true 360-degree customer view is the primary promise of the Adobe Experience Platform. If relational data used heavily in orchestration is hidden from the Profile UI, practitioners cannot easily validate data ingestion or troubleshoot personalization logic.  How would you like the feature to work The Profile UI should include a dedicated tab or widget that surfaces the underlying relational data and schema links associated with that specific profile's primary identifier. Current Behaviour Relational store attributes and cross-table relationships are not reflected in the standard Profile UI, preventing a unified “360 view” of a specific profile’s relational records

In Adobe Orchestrated Campaign (OCM) Enhance saved audiences to support incremental evaluation (entries and exits) rather than requiring full static snapshot re-evaluations. Why is this feature important to you Processing efficiency is critical when dealing with millions of profiles. Forcing a full re-evaluation is computationally expensive and delays the timely execution of campaigns that only need to trigger on net-new audience entries or exits. How would you like the feature to work Provide an option for saved audiences to evaluate continuously or incrementally, accurately flagging profiles that have recently qualified for or fallen out of the audience parameters. Current Behaviour Saved audiences function as static snapshots requiring full re-evaluation; they lack method to identify incremental entries, exits

In Adobe Orchestrated Campaign (OCM) Update the orchestration canvas UI to display unique profile counts rather than total records. Why is this feature important to you Architects and marketers rely on canvas counts for immediate sanity checks and sizing estimates. Displaying total records instead of unique profiles artificially inflates the perceived audience size, leading to misaligned expectations for campaign reach. How would you like the feature to work The numbers displayed above nodes and paths on the canvas should represent deduplicated, unique XDM profiles flowing through the orchestration step. Current Behaviour Counts displayed on the orchestration canvas represent total records rather than unique profiles

In Adobe Orchestrated Campaign (OCM) Enable the orchestration engine to dynamically re-evaluate consent and opt-in status mid-execution rather than relying on a static snapshot. Why is this feature important to you Compliance with privacy regulations (GDPR, CCPA) requires strict adherence to real-time consent. If a user opts out while a multi-day orchestrated campaign is running, they must be immediately suppressed from downstream deliveries. How would you like the feature to work The engine should natively ping the profile's consent attributes immediately prior to any delivery or action node, ensuring messaging is suppressed if the opt-in status has changed since the campaign started. Current Behaviour Consent opt in status is a static snapshot taken at the start and does not update mid execution

Provide native support and integration for Offer Decisioning capabilities within Orchestrated Campaigns. Why is this feature important to you Next-best-action and dynamic offer management are core to delivering personalized experiences at scale. Orchestration tools must be able to resolve and deliver centralized offers to ensure consistent messaging across channels. How would you like the feature to work Provide an "Offer Decisioning" node or native integration within messaging nodes in OCM, allowing the engine to fetch and append the highest-ranked offer for a profile dynamically during execution. Current Behaviour Native integration with Offer Decisioning capabilities is not currently supported