Build better products with our product team
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 objects, Another built-in option that delivers the same outcome.Clear messaging should also explain when a filter cannot apply to a report block.Business use caseOur customer needs Canvas Dashboards for operational and management reporting while still reusing existing reports and combining related work data.More broadly, this would help customers who are:Migrating from Classic Reporting to Canvas Standardizing executive or PMO dashboards Mixing Classic and Canvas reports during transition Needing one dashboard to show both parent- and child-level data.Business impactWithout this enhancement:Teams must rebuild report logic manually Dashboards behave inconsistently Adoption of Canvas slows Reporting views remain incomplete Users spend more time reconciling data manually Migration from Classic Reporting becomes harder Customer impact / scaleFor our customer, this is already limiting reporting capability and Canvas adoption.More broadly, it affects enterprises adopting Canvas Dashboards, especially those with a large investment in Classic Reports and shared dashboards used by PMO, operations, and leadership teams. Priority / urgencyHigh.This is important now because customers are actively evaluating Canvas Dashboards as the future reporting experience. If key reporting use cases are not supported, adoption and migration are delayed. WorkaroundCurrent workarounds include:Rebuilding reports as Canvas-native, Continuing to use Classic Dashboards, Splitting reporting across multiple dashboards, Recreating logic manually outside Canvas.These options are inefficient and do not fully solve the problem. Examples or scenariosScenario 1: operational dashboardA Classic Report is embedded in a Canvas Dashboard alongside Canvas-native widgets. A month filter updates the Canvas widgets, but not the Classic Report, creating inconsistent results. Scenario 2: Cross-object governance reportingA customer wants one dashboard showing project-level data together with task-level execution details. Canvas cannot fully support this, so the reporting experience becomes fragmented. Scenario 3: Phased migration from Classic to CanvasA customer wants to move to Canvas gradually by reusing trusted Classic Reports. Since embedded Classic Reports do not respond to dashboard filters, the transition becomes harder and less scalable.
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. Because Cloud Manager runs the aemanalyser-maven-plugin against the entire compiled codebase using the absolute latest cloud API surface, a background deprecation rule crossed the hard-fail threshold right as we were trying to deploy a critical backend fix.We all know why the recent AEMaaCS updates are strictly enforcing cloud-native standards. The move to hard-fail pipelines for deprecated API usage makes sense for platform stability you can't safely roll out zero-day patches if our custom code is still tethered to old, internal classes. But the current implementation is creating a massive bottleneck for development teams.Right now, when the AEM Analyser flags a legacy ResourceResolver method or an obsolete Day Commons import, it just kills the pipeline. For the dev team, this means dropping current sprint work, pulling the codebase locally, digging through Adobe docs to find the modern equivalent API, manually rewriting it, running local Maven builds, and pushing a new commit. It turns minor technical debt into a complete sprint-blocker, delaying critical user stories.The Idea:The AEM Analyser already has the exact context of what is broken, and it knows the modern API package required to fix it. My proposal is to expand the aemanalyser-maven-plugin from a passive linter into an active formatting and refactoring tool.Instead of just throwing an error and halting the ecosystem, let's give the plugin the ability to actively patch the deprecated APIs it finds. To make this practical and secure, we can handle this on two fronts:1. Locally via mvn aemanalyser:fixDevelopers shouldn't have to wait for a pipeline failure. We should be able to run a new target directly in our local terminal during active development:mvn clean install aemanalyser:fix -PautoInstallPackageThe plugin runs its standard scans, but instead of failing the build on deprecations, it applies the structural fix directly to the local source files. The developer instantly sees the git diff, verifies it, and commits clean code before it ever touches Git.2. Inside Cloud Manager (The "Secure PR" Fallback)If legacy code does slip through to Cloud Manager, we keep a strict Human-in-the-Loop model rather than blindly auto-merging code to the main branch: AST-Based Refactoring: For 80% of standard deprecations (like swapping com.day.cq.commons.jcr.JcrConstants for org.apache.jackrabbit.JcrConstants), the plugin uses an Abstract Syntax Tree (AST) engine like OpenRewrite under the hood. It refactors the Java structurally and deterministically without messing up custom formatting. Targeted AI Patching: For complex architectural shifts, an isolated, AEM-trained LLM drafts a scoped logic translation matching the current cloud API surface. The Sandbox Test: Before proposing anything, the engine runs the project's existing JUnit test suite against the refactored code inside the build container. If the tests fail, the engine safely aborts and defaults to a standard pipeline failure. The PR Handoff: If the unit tests pass, Cloud Manager pauses the pipeline, commits the fixes to an isolated branch, and automatically opens a Pull Request back to our repository (e.g., "aem-analyser-auto-fix/deprecation-cleanup"). Think About the Workflow Difference: How it works today: A custom Sling Model uses legacy Felix SCR annotations. Cloud Manager fails the build. The backend developer spends hours manually refactoring them to modern OSGi R7 Declarative Services annotations (@Component, @AttributeDefinition), rebuilding, and re-pushing. Sprint velocity takes a direct hit over unrelated legacy code. How it should work: The analyzer flags the Felix annotations. The plugin's remediation engine rewrites them to OSGi R7 standards inside the build container, runs the JUnit tests to confirm zero regression, and generates a PR. A senior architect reviews the diff, hits merge, and the pipeline resumes automatically. Quick ComparisonWhat Changes Today's Linter Approach Proposed "Fix" Feature Pipeline Action Abruptly kills the build on unrelated legacy code. Pauses, runs a test sandbox, and creates an isolated PR. Developer Effort Hours of manual context-switching and researching docs. A quick local terminal command or a 5-minute PR review. Upgrade Velocity Teams avoid cleaning tech debt because it breaks current sprints. Codebases modernize automatically, letting Adobe sunset old infrastructure faster. The Win-WinAdobe already has the DNA for this in its history, from the old AEM Modernization Tools (Classic-to-Touch UI) to the cloud migration CLI plugins (Repository Modernizer). Bringing this capability directly into the day-to-day lifecycle of the AEM Analyser is the next logical step.Adobe wants customers off legacy APIs so the underlying infrastructure can be upgraded seamlessly without breaking production environments. We want to deliver business features without fighting the CI/CD pipeline. By shifting the AEM Analyser from a tool that merely reports errors to a tool that actively generates secure, test-validated solutions, Adobe removes the final layer of friction in maintaining a truly evergreen cloud platform.Would love to hear the product team's thoughts on getting this added to the plugin roadmap!Thanks Partyush
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” that prevents someone from making changes? However… we must take into account that we still need to be able to do “adhoc” changes (that we have no intention of saving for quick insights, without having to make a copy)… but we also need a way for admins to unlock the file… let’s say someone opens it, and leaves it open and goes to meetings… if the report needs to be updated, an admin should be able to force the lock off to allow for updates. Basically, at the end of the day, we need some quality of life improvements for cross collaboration.
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, open or create a role (for example, a role named Simulation Mode), and on the Resources tab assign:Journeys → Simulate Journeys Simulated Users → Manage Simulated Users and View Simulated UsersApply the role to the appropriate sandboxes, then Save. COMPLETE WALKTHROUGH (ADMINS)How to grant Simulation Mode access (Admin) Step-by-step in Access control to assign Journeys and Simulated Users permissions: START SIMULATION MODE Go to the Journeys page. Open or create a simple journey to get familiar with the flow. Example journey used in this guide: An Optimize node with a Data source condition: two condition paths: City == London City == Chicago The journey fetches weather based on the user's city. Click Simulate, then choose Simulation. The journey moves to Draft (Test) status and Simulation Mode is active. CREATE SIMULATED USERSBefore you can test, you need simulated users. They are not AEP profiles—they are created quickly in AJO and tailored to your journey.For the London / Chicago example, create two simulated users:User 1: City = London User 2: City = ChicagoFill any other fields your journey's attribute template requires (identity, display name, and so on). Save both users so they are available for the simulation run. EXECUTE AN END-TO-END WORKFLOWWith Simulation Mode running and your two users created: Selected users — Both created users appear in the panel and are auto-selected for you. Many users later — When your inventory grows, use the expand icon to open the full list of simulated users and pick who should be part of the current run. Configure the event — This example is a unitary event journey. Event setup is straightforward: no extra attributes are required beyond what you already defined on the users. Scope who receives the event — You can select or deselect users in the simulation run. Only selected users receive the event when you send. Send — Click the send icon for each user (or send per your UI flow) to trigger the journey for that profile. Each user should enter the path that matches their city (London vs Chicago). RESULTS AND SIMULATION LOGS Scroll up and open the Results tab. Wait a few seconds for the dropdown to load. Open the dropdown to see all users in this simulation run. One user at a time — Select a single user and watch the green line on the canvas. It shows the path that user took through the journey. Node-level details — Open step or node details to see timestamps, branch decisions, and context for each step. All users — If you select All, dark grey lines show every path covered by every user in the run, so you can compare coverage across profiles at a glance. CLOSE SIMULATION MODEWhen you are done testing, stop Simulation Mode from the journey (same area where you started Simulate → Simulation). The journey returns from Draft (Test) to your normal draft state. You can start a new simulation run later; simulated users you created remain available for reuse. COMPLETE WALKTHROUGH (PRACTITIONERS) RECAPFrom access to first quick run: create a simple branched journey, two simulated users, one send per user, then read the green line in Results. That is the full Simulation Mode loop in under five minutes once permissions are in place. REFERENCESSimulate your journey
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 investments with Adobe’s future SaaS/composable direction avoid large “all-at-once” migration pressureIt would also be valuable if Adobe shared:reference architectures phased adoption patterns real implementation examples best practices for App Builder adoption guidance for handling heavily customized Commerce environmentsWould love to hear how others are approaching progressive modernization and whether a structured Adobe-led blueprint would help enterprise adoption.
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 architecturally:GraphQL APIs must be production-grade, not an afterthoughtProduct catalog data must be semantically rich, not just SEO-optimizedAdobe Commerce now supports UCP (Universal Commerce Protocol) and ACP (Agentic Commerce Protocol) : your integration layer needs to support thesePDP Enrichment adds a hidden semantic layer for LLMs without changing the human UXThe brands that will win in 2026-27 aren't just building great storefronts. They're building great APIs.
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 data is entirely unavailable
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, ...) and environment which was shown to be possible. [1] https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/developing/log-forwarding#datadog[2]
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
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
Already have an account? Login
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
