Product Communities

In Adobe Orchestrated Campaign (OCM) Expand the character limit for survey and review links stored in relational tables beyond the current 250-character maximum. Why is this feature important to you Modern tracking links, surveys, and dynamically personalized URLs heavily utilize query parameters for attribution and context, often easily exceeding 250 characters. This limitation causes broken links and truncated data. How would you like the feature to work Increase the character allowance for URL string fields in relational tables to better align with standard web practices (e.g., 2048 characters). Current Behaviour Survey and review links can be max 250 characters in relational table

OCM audiences utilized within Adobe Journey Optimizer (AJO) Journeys should retain and carry forward their specific enrichment attributes. Why is this feature important to you The true value of an Orchestrated Campaign lies in the rich data compiled during its workflow. When this data drops off as the audience enters a Journey, we lose the context required for deep, individualized downstream messaging and decisioning. How would you like the feature to work When an OCM audience triggers an AJO Journey, the journey payload should automatically inherit all enrichment attributes calculated during the orchestration phase, making them available for personalization in the Journey canvas. Current Behaviour OCM audiences used in Journeys do not carry their enrichment attributes into the journey flow.

 In Adobe Orchestrated Campaign (OCM) Extend the availability of aggregate functions (e.g., SUM, COUNT, AVG) to the Build Audience step. Why is this feature important to you Marketers often need to build audiences based on aggregated behavioral metrics (e.g., "users who have made more than 3 purchases"). Forcing this logic down into the Enrichment phase creates unnecessary complexity when it should be a primary segmentation driver. How would you like the feature to work The UI for the Build Audience step should expose the same aggregate function capabilities currently reserved for Enrichment activities. Current Behaviour Aggregate functions are currently available in Enrichment activities but not within the Build Audience step

In Adobe Orchestrated Campaign (OCM) Enrichment nodes should be able to pull fields directly from the core XDM profile, not just from linked relational entities. Why is this feature important to you The Real-Time Customer Profile is the heart of the Adobe Experience Platform. If orchestration cannot easily leverage native XDM profile attributes during the enrichment phase, it severely limits personalization capabilities and forces redundant data mapping into relational stores. How would you like the feature to work Within an Enrichment activity, users should have full access to select and pull attributes natively from the unified XDM profile alongside relational entity data. Current Behaviour Enrichment is anchored to the targeting dimension but can pull fields from any properly linked relational entity and NOT from XDM profile

 Enhance the reliability and error messaging of the preview functionality between orchestration nodes. Why is this feature important to you Data validation during the build phase is essential for trusting the orchestration engine. Vague errors prevent practitioners from effectively debugging schema or data flow issues, forcing reliance on trial-and-error testing. How would you like the feature to work The node preview should reliably render data samples. If an error occurs, the UI should provide specific, actionable diagnostic messages (e.g., highlighting exactly which schema field or table mapping failed) rather than generic fallbacks. Current Behaviour The preview functionality between nodes frequently fails with non-descriptive “something went wrong” or “table has changed” errors, hindering data validation  

Provide the ability to edit or delete Profile Target Dimensions within the Adobe Orchestrated Campaign Module (OCM) UI after their initial configuration. Why is this feature important to you Business requirements and data models evolve over time. When Target Dimensions are locked, architects are forced into rigid technical debt, requiring cumbersome workarounds if the underlying identity schema or targeting strategy changes. How would you like the feature to work Administrators should have the ability to safely modify or deprecate existing Profile Target Dimensions within the UI, provided they are not actively running in live campaigns. Current Behaviour Profile Target Dimensions are foundational, immutable objects; once configured, they cannot be edited or deleted within the UI  

There is a need for a centralized repository or UI view within Orchestrated Campaigns to easily inspect existing filter definitions. Why is this feature important to you Governance and validation are critical for enterprise deployments. Without a way to preview filter logic safely, practitioners risk accidentally altering campaign audiences during routine audits or troubleshooting. How would you like the feature to work Introduce a read-only "View Filters" modal or a dedicated tab in the OCM UI that allows users to inspect the detailed logic of an existing filter without having to enter an edit mode that risks overwriting it. Current Behaviour There is no centralized repository or UI view to inspect existing filter definitions without initiating an “overwrite filters” action within the Build Audience node

Hi, Problem: The scheduled reports are delivered without attachments after Q2 2026 release.Use case: Our team receives a scheduled report every day, but without attachments, it's difficult to see how the data looked on a particular day, especially on Saturday, Sunday and public holidays. Earlier we used to have a record for each day. Proposed Solution: I am requesting the restoration of the "Attachment" feature for scheduled reports.Enhancement from Q2 2026: 

If you have ever pasted a carefully crafted date-time expression into a Journey wait node and been greeted by a vague parser error about the plus sign, you are not alone. Journey Optimizer’s expression language is strict about how arithmetic is written, and one missing pair of parentheses is enough to block your journey.In this short guide, we walk through a real pattern: computing a wait-until time from profile data and “days from today,” then show why the expression fails and the minimal syntactic change that makes it valid. What you are trying to doA common pattern is to combine currentTimeInMillis() with a millisecond offset derived from a profile reminder date, today’s date at midnight, and a fixed offset (for example, fourteen days in milliseconds). Conceptually that is straightforward arithmetic inside toDateTime / toDateTimeOnly. The expression that triggers the errorBelow is an example of the kind of nested expression teams often build for wait logic. It is semantically reason

In workfront the only option to use regex is REPLACEPATTERN. This too has its own forthcomings. It does not allow for complex regex patterns.For example:Expected result: REPLACEPATTERN({Custom Field},”[^a-zA-Z0-9\s]”,”_”). This does not work as intended.Workaround: REPLACEPATTERN(REPLACEPATTERN({Custom Field},”\s”,”_”),”\w”,”_”)It only allows shorthand expressions. And to add special characters there is no option whatsoever. So in line with this operation we have to use REPLACE function for each of the special characters. What we wantAllow standard regex syntax to be recognised in workfront. Introduce regex function that gives a boolean as output. Or even better a whole suite of functions using REGEX and have it as a separate section just like OTHER.

Currently Workfront does not recognise double qutoes as a string literal. Even if we use an escape character it does not work. This leads to the inability of using regex patterns where we look for valid characters or other custom expression logic. Expected outcome:Allow “\”” as a valid syntax to recognise string literals in custom expressions.

Request for Feature Enhancement (RFE) Summary: Standardize the time zone display for workflow-related “Start Time / Start Date” across all AEM as a Cloud Service authoring UIs (Workflow console and Inbox) so that they are consistent and user-friendly for business users. Use-case: Business users frequently monitor and operate workflow instances (e.g., publication approval flows) from the AEM author UI. Currently, the “Start Time / Start Date” of the same workflow event is displayed in different time zones depending on the screen: • Workflow instance list vs. workflow instance history • Inbox list vs. Inbox item detail This inconsistency causes confusion for operators, makes it difficult to correlate events between screens, and increases the risk of miscommunication when discussing schedules (e.g., “when was this request actually started?”) with non-technical users. This affects daily operational work for multiple business users who coordinate publicat

We'd like to be able to create a report based on users tagged in updates/notes. For example, if someone tags me or my team in an update, I'd like to have a report on my dashboard where I can see and address each one. Since we cannot customize the in-app system notifications, simply tagging a user in an update is no guarantee that they will actually see it. Our workers have hundreds of updates flooding in each day, so for the most part the entire notification system has become useless for this purpose. Although our workers each have the email notification setting turned on for when they/their team is tagged, those emails don't always come through, making it a spotty system at best and not reliable for ensuring each tagged update is addressed. With a report filtered by who was tagged in any given update/note, my team can trust that they're not missing anything important. Bonus points if there can be a way to "dismiss" updates that don't require a response (