Build better products with our product team
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
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.
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.
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.
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.
I recently had a very frustrating time trying to figure out how we could use delegations when people are away. I see a few have posted on this subject. Here’s my two cents worth. Current Method User goes to Workfront Home/Worklist page. Click Delegations. Enter a date range and delegate, Save. This creates a delegation for the user's tasks that have a Planned Completion Date in the specified date range. The delegate can now perform the delegated tasks, issues, approvals etc as long as they have the appropriate Access Level. Problems Delegation delegates specific tasks to the delegate rather than just allowing the delegate to perform any of the delegator's tasks during their absence. The delegated tasks are those with a Planned Completion Date in the specified date range. The Start Date of that range cannot be earlier than today. Any tasks with a Planned Completion Date before the start date cannot be delegated. These would be the oldest tasks the delegator has outstanding and thus the most in need of delegation and work. The delegated tasks cannot be seen anywhere except in the Worklist. We don't use the Worklist at all. All users have a dash with reports of work that needs doing. The delegated tasks cannot be reported on. The only reference to delegations in the standard reporting system or API is the USRDEL object. This object can be used with an EXISTS filter to report ALL the tasks assigned to the delegator, viz: EXISTS:1:$$OBJCODE=USRDEL EXISTS:1:fromUserID=FIELD:assignedToID EXISTS:1:toUserID=$$USERID However there does not appear to be a method where that can be restricted to tasks that can actually be performed by the delegate i.e. those with a PCD in the range. Suggestions Change the method of operation so that delegation provides the delegate with permissions to perform ANY of the delegator's assigned tasks/issues/approvals during their absence (given they have the appropriate access level). The date range should be when the person will be away - Planned Completion Dates then have nothing to do with it. OR If we must use the current method of delegating specific tasks by date range of Planned Completion Dates, allow the Start Date of the range to be in the past so older, urgent tasks can be included in the delegated work. Provide reporting tools so that delegated tasks can be included in reports of assigned and delegated work by user. How does the Worklist pick them up? Allow a user to delegate their work to multiple people, or perhaps a team, so the work can be spread around. Provide the facility for planners/managers to create delegations for others in their groups/teams. No doubt others will also have some suggestions.
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
When using Tab or Accordion components in a page, an issue occurs where, after editing a component on the second or subsequent pages and then closing it, the view unintentionally returns to the first page.Expected behavior: When editing components on the second or subsequent pages, the user should remain on the edited page and be able to continue working without being redirected to the first page.
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
Allow the selection of Email channel configurations in the OCM UI even if they contain more than one target dimension. Why is this feature important to you Enterprise setups often utilize configurations with a target plus secondary dimensions. Forcing architects to change their design and create a dedicated channel setup specifically for OC adds administrative overhead and fragments channel governance. How would you like the feature to work The OCM UI should gracefully handle and permit the use of channel configurations that include multiple target dimensions without causing canvas failures. Current Behaviour Orchestrated Campaigns require a channel configuration with exactly one target dimension, and configurations with a secondary dimension fail in the campaign canvas
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
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
