Build better products with our product team
Marketo Engage users who have significant investment in email assets build in the legacy email designer need a “push button” way to convert old email assets to the format used by the new email designer. Adoption of the New Email Builder is being hampered because New Email Designer assets are fundamentally different asset types, and switching to the new email editor for organizations that have significant investments in nurture programs are akin to doing a full Marketing Automation migration, which is not to be desired.
Behavior (current)When a reviewer/approver opens a proof via the Proof HQ direct link, the decision buttons (e.g., approve / changes required) do not display. When the same proof is opened via the Workfront proof link, the decision buttons display correctly. Suggested feature ideaEnable the decision buttons in the Proof HQ direct link proof viewer whenever the user has decision permissions for that proof, so reviewers can complete approvals regardless of whether they access the proof from the Workfront link or the Proof HQ link.
WorkFront has no ability to 'undo last action' - in some cases this can be very troublesome - as it is quite easy to make a change to basic project behaviour, critical path and end dates. An 'Undo' last change function would be very useful if the Project owner has in-advertantly made a change that has caused multiple activities to be impacted. Even a - revert to last saved version function might be useful - at least allowing the project owner to go back to a version that they have already reviewed and approved with their team.
Many content-rich websites with extensive knowledge bases are experiencing a significant increase in traffic from AI scrapers, crawlers, and data harvesting bots. In our case, this has been an ongoing challenge for several months. While the impact on reporting accuracy is already substantial, the more immediate concern is the associated increase in Adobe Analytics server call consumption, which can lead to unexpected overages and additional costs.What makes this challenge different from traditional bot traffic is that these are not a small set of well-known bots that can be managed through static signatures or conventional bot rules. The traffic is highly distributed, frequently changes behavior, and often originates from a large number of sources, making it significantly harder for customers to identify and mitigate on their own.Given the broad impact across digital analytics implementations, could Adobe consider a more proactive partnership model with customers? For example:Maintaining and publishing regularly updated AI scraper/bot signatures or detection patterns. Providing monthly or near real-time updates that customers can leverage at the network, CDN, WAF, tag management, or Analytics processing level. Offering enhanced detection capabilities within Adobe Analytics that specifically address emerging AI crawler traffic patterns. Creating a community-driven process where customers can contribute observed signatures and suspicious traffic sources that Adobe can validate and distribute more broadly.Without stronger ecosystem-level support, organizations risk both increasing operating costs and declining confidence in the accuracy of their analytics data. As AI-driven crawlers continue to evolve, an industry-wide challenge requires a more adaptive approach than the traditional bot management strategies that were effective in the past.I would be interested to hear whether Adobe is considering any roadmap investments or customer collaboration initiatives in this area.
When custom objects get data transmitted initially, this is “Added to Object” activity that gets logged; however, there was times where this information then gets updated; such as status changes or watch times updated. There are triggers for “Custom Object is updated” however, since update activities are not logged in the Activity Log, then trigger tokens get skipped and logic flows get skipped. I have this case E-002408984 from a Marketo program that I was trying to create logic on Samples orders and to create an interesting moment. If you are added to Sample Object as status shipped, then pull trigger tokens for PN, Qty and ship date into an interesting moment. I also added if Sample object is updated, status changes to shipped, then pull trigger tokens for PN, Qty and ship date into an interesting moment; however, these were failing anytime “updates” were done on a prospect. Sample items can come in daily as “processing” and then next API call can be updated as ‘shipped’ hence why I created a trigger logic on “Sample order is updated”. Currently these update activity trigger tokens are getting skipped and my logic is failing because the trigger tokens cannot be found since Update Activities are not tracked in the activity log. Ideally, same for when we use our On24 custom object and a prospect watches registers & then watches a webinar, we would like trigger tokens to call on the updated activity for after their time watched gets updated and we can run logic based on these trigger token updates. We would like to see functionality added for Custom Object “Updates” in the activity log so trigger tokens can be utilized.
The Mention widget should automatically prioritize active conversations by moving any existing thread with a newly added comment to the top of the widget. This would improve visibility and help users quickly identify and respond to recent activity.Currently, users must scroll through the widget to locate new comments if the original thread was created some time ago, since thread placement is based on the thread's start date rather than the most recent comment. Reordering threads based on the latest activity would create a more intuitive and efficient user experience.
SUMMARYMake open tracking a per recipient decision driven by a person field, evaluated at send time, instead of an asset level setting. One email asset would then serve both consenting and non consenting recipients, and native Opened Email activity would still be generated for the consenting recipients only.TODAYThe only control over the open pixel is the asset level flag isOpenTrackingDisabled, exposed as the "Disable Open Tracking" checkbox in Email Settings and on the Emails Asset REST API. It is all or nothing for the asset.Adobe's own CNIL guidance therefore instructs customers to build two variants of every email, one tracked and one untracked, plus a Smart Campaign Choice step on a consent field to route recipients between them. Adobe Support has confirmed this is the only supported approach.Setting isOpenTrackingDisabled to true suppresses the pixel for every recipient of that asset, and Opened Email is a system activity that cannot be written back through the REST API, so there is no supported way to retain native open reporting for a consenting subset from a single asset.WHY THIS MATTERSThe CNIL recommendation on email tracking became applicable on 14 April 2026, with the transition period for pre existing contacts ending 14 July 2026. The Italian Garante deadline is 28 October 2026. Any organisation sending marketing email into France or Italy is now obliged to obtain consent before measuring opens for campaign performance purposes.The two variant workaround imposes a permanent and compounding cost:1. Every email asset must be cloned, and both copies edited, reviewed, approved and quality checked for every send. The duplication multiplies by the number of affected locales.2. The two variants drift. A late content change applied to one copy and not the other ships an inconsistent email, and nothing in the product flags the divergence.3. Reporting fragments. Metrics for one send are split across two assets and have to be recombined by hand outside Marketo.4. Leads whose consent field is null are routed to the Default Choice, which sends the tracked variant. Getting this right requires an explicit backfill of every existing person record, and a single missed backfill tracks people who never consented.None of this is a content or design problem. It is one boolean per person that the platform already stores and already evaluates at send time for Choice steps and for Velocity.PROPOSED BEHAVIOURAllow the open pixel injection decision to reference a person field. For example, a third state on the email asset alongside enabled and disabled, such as "Open tracking: driven by field", with a field selector, so that at send time Marketo injects the pixel only for recipients whose selected boolean field is true.Expected outcomes:One asset per email, no clones.Opened Email activity generated for consenting recipients, exactly as today.No pixel and no activity for non consenting recipients.Email Performance Report open metrics describe the consenting population, with the untracked population excluded rather than counted as unopened.Exposed on the Emails Asset REST API alongside isOpenTrackingDisabled so that the setting can be applied programmatically across a large asset library.Marketo already evaluates person fields per recipient at send time for Choice steps, dynamic content and Velocity. This asks for that same evaluation to be applied to one existing platform behaviour.RELATEDCompanion idea covering the equivalent problem for click tracking: link rewriting suppressed per recipient rather than per link.Adobe CNIL guidance: https://experienceleague.adobe.com/en/docs/marketo/using/product-docs/email-marketing/email-designer/cnil-guidanceEmails Asset API, isOpenTrackingDisabled: https://experienceleague.adobe.com/en/docs/marketo-developer/marketo/rest/assets/emails
We cannot get the Computed Attributes value distribution to show anything but non-zero values. We were recently informed by Ultimate Support that a minimum success rate of 30% is required for Computed Attributes. This is also where we learned that the 30% was not only a minimum threshold for the Value Distribution/Sample Profiles QA piece, but also for getting the Computed Attribute in and of itself to populate at all. This is an extremely high target threshold and unrealistic for many of our real-world applications. We did ask Ultimate Support if and how clients have adopted Computed Attributes given those requirements and we learned that there have not been many Adobe clients who have, and confirmed that many other clients have expressed similar concerns as we have. Can the Computed Attributes value distribution minimum success rate be optimized & improved beyond the current 30% minimum threshold?
We cannot seem to get the Value Distribution for Computed Attributes to show any non-zero values? We were recently informed by Ultimate Support that a minimum success rate of 30% is required for Computed Attributes. This is also where we learned that the 30% was not only a minimum threshold for the Value Distribution/Sample Profiles QA piece, but also for getting the Computed Attribute in and of itself to populate at all. This is an extremely high target threshold and unrealistic for many of our real-world applications. We did ask Ultimate Support if and how many clients have adopted Computed Attributes given those requirements and he shared that there have not been many Adobe clients to his knowledge who have, and confirmed that many other clients have expressed similar concerns as we have. Hence the idea & feature enhancement request raised here.
The Adobe Analytics API 1.4 is scheduled for decommissioning this summer, yet critical endpoints from this legacy API have not been integrated into API 2.0. This creates a significant gap in functionality that will impact many organizations relying on programmatic management of Adobe Analytics configurations.Missing Critical Functionality:The most important missing feature is the ability to programmatically:Create new Adobe Analytics variables (props, eVars, events) Modify existing variable configurations Delete variables when no longer neededCurrently, API 2.0 forces users to manually manage these variables through the Adobe Analytics interface, which is:Time-consuming for bulk operations Error-prone for complex configurations Incompatible with automated deployment workflows Difficult to integrate with CI/CD pipelinesBusiness Impact:Without this functionality in API 2.0, organizations will lose the ability to:Automate variable management across multiple report suites Maintain consistent configurations through code Integrate Analytics setup into their development workflows Scale variable management efficientlyRequested Solution:Please add endpoints to API 2.0 that provide full CRUD (Create, Read, Update, Delete) operations for Adobe Analytics variables, matching or exceeding the functionality currently available in API 1.4.This is essential for maintaining operational efficiency and preventing workflow disruptions when API 1.4 is discontinued.En savoir plus :1image.png
Problem / Current Limitation:Currently, Content Fragment Models (CFMs) in AEM do not support version tracking. When a model's structure (fields, data types, validation rules, etc.) is modified, there is no way to see:What specifically changed (which field was added, removed, renamed, or had its type/config altered) Who made the change When the change was made Why the change was made (if a comment/reason was provided)This creates accountability and governance gaps, especially in environments where multiple authors/developers manage models that drive content used across channels. Untangling the impact of a model change (e.g., a breaking change to a field type) after the fact is difficult or impossible today.Proposed Enhancement:Introduce native version history for Content Fragment Models, similar to how AEM Pages already support versioning. Specifically: What to track: Model structure changes: field additions/removals/renames, data type changes, validation rule changes, default values. Metadata changes: title, description, tags. Who made the change (author/user ID) and timestamp. Optionally, a diff/comparison view between two versions. How to acquire this information: Leverage AEM's existing JCR versioning framework (mix:versionable) applied to the CFM node structure, similar to page versioning. Capture change events via JCR observation / workflow launchers on cq:dialog/model node updates. Store user and timestamp via standard jcr:lastModifiedBy / jcr:lastModified properties, extended to grant granular field-level diffs. Where to store it: Store versions in the JCR version history workspace (/jcr:system/jcr:versionStorage), consistent with existing AEM versioning patterns. Expose version history through the Content Fragment Model editor UI (a "Version History" panel/timeline, similar to the Page Properties version tab). Optionally expose via API (CFM Management API / GraphQL) so version history can be queried programmatically for audits. Why it matters:Improves governance and accountability for teams managing shared content models across large organizations. Reduces risk of untracked breaking changes affecting content authors and downstream integrations (GraphQL persisted queries, headless delivery). Enables rollback to a previous model version when an unintended change causes issues. Aligns CFM capabilities with existing page/asset versioning features already in AEM.
Description - When a users share a segment with a group of users or individual, there should be an option to decide edit rights - edit copy or edit original. Why is this feature important to you - Our Analytics community is mixed with foundational to advance users and we are often sharing components based on expertise level. This feature would help us to democratize more of the IP across teams. How would you like the feature to work - The sharing prompt should work much like workspaces. Edit copy - Edit Original- Read Only. Current Behaviour - Today we can only ask the user to clone segments from the components section, if they want any specific universal segments OR work based on trust that the user wont make an update and would be careful.
Our team has a need to make the filter selection in the My Approvals widget sticky. We have multiple team members that submit work to others for approval and receive work from others for approval. Having to reset the filter each time to show only “My Approvals” instead of “All” wastes a few clicks of time and makes it more difficult for us to work through time-sensitive approvals.
When users select the Search icon, it is natural to expect all relevant results to be visible on the first page. Currently, when our users are “searching” in Programs, the results are either not showing on the first page, or one is showing on the first page with the remainder displaying on different tabs/pages.WF Support has said that currently, this is due to the existing pagination behavior and is a product limitation. Unfortunately, this is causing confusion among our users.Thank you for your consideration.
Request for Feature Enhancement (RFE) Summary: Provide a notification functionality for translation projects which informs a defined group of the translation project about the completion of a translation, listing all pages that have been translated so that you just need to click on the link to open the pages, review and publish them. Use-case: As an editor which has started a translation job, I want to be informed once the translation is back in AEM in order to check and publish the page. Current/Experienced Behavior: There is no functionality inside the Translation Project, you have do a customization by yourself. Improved/Expected Behavior: As the information about completed translation jobs is essential and no editor wants to check frequently the status of the translations projects, especially when there are hundreds running, I would expect that there is an ootb functionality for that. In the project you already have the chance to add member - here you could simply define the recipients for a completed-mail. This feature would be helpful for every customer using the Integrated Translation Framework! Environment Details (AEM version/service pack, any other specifics if applicable): Customer-name/Organization name: Carl Zeiss AG Screenshot (if applicable): Code package (if applicable):
When using the filter “Member of Program” in a smart campaign, the dropdown shows all program statuses. It would be much more useful if it only displayed the Program Statuses for the channel of the selected program. I can’t think of a reason why when you’ve chosen a specific program, filtering on statuses not tied to the program’s channel would be needed.
Version 1 of the callable agent functionality is very cool. It would be great as a follow to create a visual agent builder (think “drag & drop” or using the “journey metaphor”) that can be used natively inside of Marketo, similar to tools like n8n, and enable an “callable agent journey” to be able to interact with other agents in the system, in the same way that Marketo smart campaigns can engage with executable campaigns.
I love the functionality that you have enabled with callable agents and the webhook (future flow step) application. What I would like to see as a next step is the ability for agents to execute other functions in Marketo beyond sending back return attributes to populate fields. Here are some recommendations for capabilities to add to callable agents:Add to List Insert/Upsert on lead database fields across objects (Program Member, Marketo Custom Object) Change Program Status Add/Update to Salesforce Campaign. Conditional logic for change data value (rather than merely send back responses)
I would like to share a key feature enhancement request for Adobe Experience Platform (AEP) Real-Time CDP architecture regarding data modeling flexibility. Ideally for B2C, B2B & B2P editions as we have consolidated all into single Prod & Dev sandboxes as advised by Adobe Ultimate Support.The Feature Upgrade:Enable native Many-to-One (N:1) schema relationships between non-B2B XDM schemas. This will allow multiple custom data records to link directly to a single parent account record within standard XDM profiles, without requiring both B2B XDM classes.Use Case & Business Need:Current Scenario: We have custom data entities (e.g., competitor products, telemetry, certifications) where multiple rows of data map to a single core business account. The Problem: Standard non-B2B XDM schema relationships are restricted to lookup options, which force data into arrays. This results in complex architecture and confusing schema building UI. Proposed Solution: A flexible parent-child relationship model that natively links N custom data rows to 1 parent account row in the Profile Service.Value & Impact:Cleaner Data Architecture: Eliminates the need for complex array manipulation. Smarter Audience Segmentation: Allows segment builders to have distinct paths to attributes, and creates cleaner backend data models. Speed to Value: Avoids architectural re-engineering/forced schema workarounds just to support custom relational data models.
At present it is not possible to disable the 'Select All' function for checkbox fields. It would be very useful to be able to deselect/disable this functionality for each checkbox field in the Admin layer of the form builder.
A checkbox for "ALL" appears by default on custom forms when using the checkbox feature. It happens after a certain number of choices are listed. We don't want our clients to be able to click ALL as it will prevent the client from really thinking through what they need. We don't want our clients to be able to click ALL just because it's faster.
In the old SAINT data export user-interface, we had the ability to filter the results exported based on number of rows (which we can still do), dates (which we can still do) and key values (which we cannot do). When we are addressing data changes by our users and trying to update a subset of the page classification values, this ability to fetch only a subset of the data that needed to be addressed was critical. Sadly we no longer have that ability in the new classification set interface. If it could be added back, that would be a tremendous boon for us. I know we can get this via the API, so the underlying code is there, it would be great if it were added back to the user interface as well.Thanks!
When updating the panel date ranges, the Comparison Dates stay the same. This means we as users have to delete the old comp dates and percentage change metrics, then create new ones. On bigger “recycled” dashboards, this takes FOREVER! This one improvement would save me hours and hours and hours every year.Thanks! RR
Adobe Target appears to interpret ${} as Target variable/token syntax, which conflicts with JavaScript ES6 template literals.For example:let x = 'Testing var';console.log(`Value: ${x}`); Instead of printing:Value: Testing varthe content inside ${} gets removed or replaced during Target processing, resulting in unexpected behavior.As a workaround, developers must use string concatenation:console.log('Value: ' + x); It would be helpful if Adobe Target could either:Support JavaScript template literals without preprocessing ${} expressions. Provide an escape mechanism for JavaScript template literals. Document this limitation and the recommended workaround in the official documentation.This would prevent conflicts between Adobe Target token replacement and standard JavaScript syntax, making custom code easier to write and debug.
Event Forwarding governance and optimization are becoming increasingly difficult as implementations scale and additional rules are introduced. While the current monitoring experience provides an aggregate compute-time view, it lacks the visibility needed to understand which individual rules are responsible for overall resource consumption. This creates a significant operational challenge because teams can identify that compute-time usage has increased, but they cannot determine what is driving the increase, which rules are contributing the most, or where optimization efforts should be focused. As a result, troubleshooting becomes highly manual, requiring teams to review rules individually, make assumptions about potential bottlenecks, and perform extensive testing without any data-driven insights.To address this gap, the Event Forwarding monitoring UI should provide rule-level compute-time attribution that allows users to understand exactly how much compute time each rule consumes during execution. The monitoring experience should surface detailed metrics for every rule, including total compute time, average compute time per execution, maximum and minimum execution duration, execution count, percentage contribution to overall compute usage, and historical trends over time. Users should be able to sort and filter rules by compute consumption to quickly identify the highest-cost rules within their implementation. Additionally, the interface should provide visual indicators that highlight anomalous behavior, such as sudden increases in compute consumption or rules that consistently exceed established performance thresholds.The solution should also enable users to drill into periods of elevated compute usage and immediately determine which rules were responsible for the increase. For example, if a property experiences a significant compute-time spike on a specific day or during a specific hour, users should be able to navigate directly to that timeframe and view a ranked breakdown of the rules contributing to the spike. This level of transparency would dramatically reduce investigation time and allow engineering teams to focus on the rules creating the greatest operational impact. Historical trend analysis should further allow users to compare rule performance across reporting periods and identify regressions following rule deployments or configuration changes.Beyond troubleshooting, rule-level compute visibility would establish stronger governance capabilities across Event Forwarding implementations. Organizations could leverage the data to define performance standards, identify opportunities to consolidate redundant logic, optimize custom code, and proactively manage platform resource consumption.The ability to understand compute usage at the rule level would enable teams to make informed architectural decisions, improve operational efficiency, and ensure sustainable growth of Event Forwarding implementations. Ultimately, this enhancement would transform compute-time reporting from a high-level health metric into an actionable optimization tool that provides the transparency necessary for effective monitoring, troubleshooting, and governance of Event Forwarding rules.
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.
