Product Communities

Product area / feature areaAdobe Workfront > Reporting > Canvas DashboardsSub-areas: dashboard-level filters/prompts, Classic Report interoperability, cross-object reporting Current behaviorCanvas Dashboards can include existing Classic Reports, but dashboard-level filters/prompts do not apply to those embedded reports. Filtering only works consistently for Canvas-native reports.Canvas also has limited support for combining related-object data, making it difficult to build reports that bring together fields like Project + Task in one view. Desired behaviorDashboard-level filters/prompts should apply to eligible embedded Classic Reports so users can filter all dashboard blocks consistently.Canvas should also support stronger cross-object reporting so users can combine related data in a single dataset or visualization without duplicating logic or relying on external workarounds.At minimum, this could include:Full support for related-object fields, Supported join model for related o

Hi Team,Last week, my team needed to deploy an urgent, time-sensitive hotfix. The fix itself was incredibly minor just a two-line null-check update inside a core OSGi service. We tested it locally against the latest SDK, the PR was approved, and we kicked off the Cloud Manager production pipeline.Twenty minutes later, the pipeline abruptly halted with a Hard Failure at the Code Quality step. I pulled the logs, expecting a missed unit test, but instead found this:[WARNING] [region-deprecated-api] ... Usage of deprecated package found: com.day.cq.commons.jcr.JcrConstants. For removal: 2026-06-11[ERROR] Rule region-deprecated-api failed. Build halted.Because of the strict API deprecation gates rolled out in the recent 2026 releases, what used to be a passive log warning had instantly become a deployment blocker.The frustrating part? The code that failed was not even part of our hotfix. It was an old legacy utility class deep in our core Java bundle that hadn't been modified in three years

Teams who collaborate on Workspaces have a lot of potential issues to lose / overwrite work from others in their team. There is no “lock” feature to prevent multiple users from accessing and updating the same report at the same time, which can lead to lost efforts by the last person saving their version, and “wiping out” the other person’s work. There are lots of potential options to help mitigate this, and it may end up being a roll out of features, since there are definitely complications for designs. Options:At least show visually how many people (and maybe who) are actively on a Workspace at a given time… or at least showing how many people with Edit rights have access. This way there is some warning that you might be impacting someone else’s work when you are there. For multiple active users, if I make a change and try to save, there could be a warning that my changes aren’t the most recent… and maybe provide a way to merge the other recent save with my own? Implement a “Lock” tha

Currently the list of classifications on the the Classification Set page (in the new Classification sets interface) does not have an option to show if a classification is active or not. The old interface did.  Including that flag is useful to easily see which classifications, in a potentially long list, are currently active. To see that in the new interface requires two clicks to see the status and a third click to get back to the list. If one is working on a number of conversions you might want to see which you have not made live. Currently you have to click into each item in the list and keep a separate note (or have a really good memory) to keep track.

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

Hello, Would it be possible to add an default view override option for each custom report that will allow users to select their custom view as the default view for the custom report instead of report's default view? Right now, the only way to change the default view of the report is to change the report itself, meaning you'll need to create a copy of it, because typically reports are shared. Of course, a user can always select the view that they want for the custom report, however, that setting is reverted back to report's default view each time the report is loaded. It would be nice to have a the ability to make the report's default view = user's chosen view for that user's account. In terms of UI it could look something like this: Thank you, Andrey

When investigating API user activity, Marketo currently only provides visibility into the number of API calls made by a given user. However, when trying to determine what a specific API user changed or created on a person record, the process is not straightforward.Adding a dedicated Smart List filter or activity constraint that allows users to identify actions performed by specific API users would be extremely valuable for troubleshooting, auditing, and debugging purposes. This enhancement would significantly improve visibility into API-driven changes across the platform.

Many enterprise Adobe Commerce customers are interested in modernization, but a full immediate transition to composable or ACCS is often difficult because of existing customizations, integrations, operational dependencies, and business risk.A possible approach could be an officially documented “progressive modernization blueprint” that helps organizations move step-by-step instead of forcing a large transformation program.The idea would be to provide guidance around:introducing App Builder gradually alongside existing PaaS implementations identifying which customizations should move first to extensibility services preparing APIs and event-driven integrations early coexistence strategy between legacy modules and composable services phased operational governance and monitoring ACCS readiness assessment framework recommended migration sequence for enterprise implementationsThis could help customers:reduce migration risk modernize incrementally improve long-term maintainability align inves

When a user clicks 'Request Access' on a project they can't view, they're presented with a dropdown of everyone who has Manage access - but there's no context to help them choose the right person.The Project Owner is the most logical recipient for these requests, and they're already first in the list. A simple (Project Owner) label next to their name would give requesters the context they need without cluttering the list.Attaching a screenshot as an example. 

Your storefront now has two audiences. Most architectures are built for only one.Adobe summit 2026 made this crystal clear: AI agents are actively shopping on behalf of consumers and most storefronts aren't built for them.During the 2025 holiday season, generative AI tools drove a 693% increase in traffic to retail sites year-over-year. And those AI-referred shoppers convert 31% higher and generate 254% more revenue per visit.The two audiences your storefront must now serve:HUMAN SHOPPERS (you know this one):Browse pages, use search, click through checkoutRespond to promotions and personalized recommendationsUX, Core Web Vitals, and page performance still matterAI AGENTS (new requirement):Query your catalog via API : they never see your homepageCompare products across multiple LLMs on behalf of usersExecute purchases autonomously using protocols like UCP and ACPNeed machine-readable product data: rich descriptions, structured specs, real-time pricing and inventoryWhat this means archit

Currently it is not possible to identify whether a Dashboard is still being used. We need a default View which shows this, same as is available for Reports.

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

Hello,Having contacted Adobe AEM support who confirmed that this does not currently exist, I am creating this idea to see whether there is support in the community for this feature. With the deprecation of the OpenTelemetry library (from the aem-commons project, I think), we no longer have log-forwarding to Datadog.We know that there is a self-service setup for log-forwarding to Datadog and other monitoring solutions [1]. However, what is missing there is the possibility to restrain logs by log level (such as DEBUG, INFO, WARN, ERROR, and FATAL). We understand that we could remove logs from Datadog after ingestion, but Datadog is paid for the ingested data (whether you use it or not), so this is not an option for us.Therefore I’ve opened a RFE to add this filter. Please let me know whether you are interested in having this feature. Thank you,Jakob.PS: Note that my request is similar but different from this existing one [2] which asked for filtering by log type (cdn, error, access, ...)

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