Build better products with our product team
Request for Feature Enhancement (RFE) Summary: Chance to select which kind of assets(original or renditions or both) to download from shared assets. Use-case: AEM as Cloud Service: when I share multiple assets with a user through the Share functionality, the receiver can't choose if they want to download only the original assets or the renditions, it automatically downloads whatever was set up by the person initiating the share. Current/Experienced Behavior: When I share multiple assets with a user through the Share functionality, the receiver must download whatever was set up by the sender, not for folders or collections. Improved/Expected Behavior: The requirement is for the person receiving the assets to be able to specify what they want to download, similar to the functionality present when you just use the DAM as a normal user, both for folders and collections. Environment Details (AEM version/service pack, any other specifics if applicable): 2024.11.18598.20241113T125352Z-241000 Customer-name/Organization name: Jet2 Screenshot (if applicable): Code package (if applicable):
前提Marketoの仕様として、同一アドレスへの配信はIDが古い方に配信されると思いますしかしABテストで配信する場合、テストと勝者の2つのメールが配信されてしまう仕様になっていると思います。これは、プログラムの内部でテストと勝者にそれぞれのスマートキャンペーンが生成されるためと理解しています。 参考リンクアイデアABテストを使用したメール配信でも、重複したアドレスには1メールしか送信されないような仕様に変更いただきたいです。
Wants flexibility to do cross device targeting for some experiences and to not have to do it for all as in certain cases they don't won't experience switching to happen .Ref: Real-time profile syncing for mbox3rdPartyID
Community Manager Edit:This idea is being archived as a duplicate. Please direct all votes, comments, and questions to the new idea.New Idea - Reference Data Elements | Automatically Update Names of Data ElementsAs mentioned before Automatically Update Names of Data Elements Used in DTM Rules with 10 votes by user: @jon_kranzPROBLEMChanging the name of a Data Element does not automatically update the name of the same element when it is used in any Launch rule.SUGGESTED SOLUTIONIF the name of a Data Element has been updated AND that same Data Element is referred elsewhere within Launch (be it a rule or installed tool or anywhere else it is used)THEN system will automatically update the name of the Data Element anywhere it is used.**Note: This solution would exclude areas where custom scripts are permitted. My naive assumption is that having the system change custom scripts would be a very bad/problem-causing idea.Adding support to update _satellite.getVar('dataElementName'); should be in this scope as well, I don't see why this would cause issues since its a simple string replacement.Thanks for listening.
It would be fantastic if we had the ability to set our own fiscal year in a calendar/schedule or even at the company or group level. This would help immensely for reporting purposes.
Hi, as a product enhancement in the future it would be great to be able to use Dynamic content (language) in an email and have that reflect in the view as a webpage preview. Currently only the default (English) version shows when you click view as a webpage for emails that contain other languages.
As a system administrator I would like to get notified about new and pending user approvals, so I can activate (approve or reject) new users from user creation approval request. Post Adobe Admin Console migration, only system admins are allowed to create new users form within Adobe Workfront. Group admins/users with "create" (edit) rights for users can only submit new users for approval. A system administrator has to approve this request. Currently, there is no notification (neither within Adobe Workfront, nor via email) for such request. Hence, nobody receives these requests and users stay unapproved (without access to Adobe Workfront). The current workaround is to scan the Users list filtered by "Pending Approval" manually, or to send a report with pending approvals frequently.
Hi all, To enhance the security of our domain, https://planonsoftware.com, we are working to enable nonces in our Content Security Policy (CSP) header. As part of our testing phase, we enabled nonce support in Reporting Only mode in our development environment. During this process, we encountered an issue with Marketo. Marketo injects a <style> tag for the tool 'modernizr', which doesn't comply with nonce-based CSP. We considered adding the hash of the modernizr file to our CSP, which could solve the issue temporarily, as suggested in another Idea. However, this solution would break if Adobe Marketo changes the script in the future. Therefore, it would be ideal for Marketo to address this issue directly by supporting nonces, as it's a basic security best practice.P.S. We also reported this as an issue (Case Number 02814654), but since it was classified as new functionality, it wasn't resolved. We were directed to raise an Idea here on Marketo Nation so that the Product Management team can review it for the roadmap. I'd strongly encourage prioritizing this issue to align with modern security standards.
Request for Feature Enhancement (RFE) Summary: To have the ability to undo the move or deleted assets/pages Use-case: Sometimes we want to revert the bulk moved or deleted assets or pages, but we don't have any recycle bin or undo changes option Current/Experienced Behavior: No option to get back the deleted or undo the moved assets or pages Improved/Expected Behavior: We should have undo option in the action bar just like paste so that we can get back the unintentional action results Environment Details (AEM version/service pack, any other specifics if applicable): Customer-name/Organization name: Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Ability to re-baseline RDE environment after reset / Backfill code image from Prod to other environments Use-case: After a production release we backfill our environments. This is done by executing pipelines for the various Dev environments however this could be different to whats deployed to production depending on when the master branch was deployed.For our RDE environments however, this is manual and when we have multiple RDE's for our developers its a time consuming task to reset each environment. It would be great if we could simply select an image that has previously been deployed to an environment such as Production and be able to deploy that to any dev/rde environment without having to run a build pipeline.This would minimise effort from executing multiple pipelines and manual effort and would also minimise processing by Adobe as the image would already be built and validated. Current/Experienced Behavior: Manual for developers to deploy code after resetting it Improved/Expected Behavior: Create the ability for an environment to be backfilled based on an image that has already been deployed Eg: Production code image can be deployed to Dev & RDE Environment Details (AEM version/service pack, any other specifics if applicable): AEM cloud manager Customer-name/Organization name: Spark NZ Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Allow to search for Assets by combination of options e.g. Created by, Created Date and Modified Date Use-case: goto aem activate filter Select created date - in last 2hours (same for all options) Select modified date - in last 2 hours (same for all options) Current/Experienced Behavior: Tick box now removed from created by and added to modified by Improved/Expected Behavior: Would expect to be able to filter by all 3? Environment Details (AEM version/service pack, any other specifics if applicable): AEM Assets CS, AEM Release ID 18175 Customer-name/Organization name: Jet2 Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Dispatcher GUI Use-case: Dispatcher management Current/Experienced Behavior: Not often it is cumbersome to develop, manage and trroubleshoot Dispatcher configurations, including those specifically belonging to Apache HTTP server. Improved/Expected Behavior: - I remember that back in the days there was a pretty good UI tool for managing Apache HTTP related configurations. It was called http://www.apache-gui.com/apache-windows.html and we can refer to it and check it out to see how it works.- I would propose to have a similar tool for managing Dispatcher configurations. Everything should nicely be viewed in a visual editor. It may contain hints and preferably validators that can be used during editing. The core engine for the tool can either be developed from scratch using maybe ANTLR or it may reuse the stuff that Adobe uses internal to read, interpret and apply the Dispatcher config. - I would be more than glad to participate and contribute to development of such tool. Environment Details (AEM version/service pack, any other specifics if applicable): For both on-premise and AEMaaCS. Customer-name/Organization name: Techich.com Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Provide a means of permission and user-management for AppBuilder Applications (through Adobe IMS, AdminConsole) Use-case: When developing App Builder Apps, the question occurs how to give different users different permissions within the App (or access to the app at all).How can access to an App be granted or denied - and what about granual permissions within the app?How is permission-management / user-management within Appbuilder Apps handeled?IF we do not yet support something like that ..I think each app should have the ability for product profiles in the admin-console, which could then be customized to have as many different permission levels as required by creating additional profiles.(Naturally these should be easily available on runtime "OOTB" for developers to use. And not though something like the UMAPI - which is very cumbersome ... ) Current/Experienced Behavior: Unfortunately ORG level is the only granularity in terms of access to an app which is way too broad. Everything else currently needs to be handled within your app.IDPs like Auth0, cognito, supabase, must be integrated directly into the app (so only "non-Adobe IPDs can be used). This is not simple when you inevitably get into MFA, SSO, password rules enforcement, fraud detection, etc Improved/Expected Behavior: I'd also like to see more fine grained control built in on our side, e.g. via profiles added to an IO project, which would change the required scopes to invoke the action, so only users with that profile/group would be able to access it with their token Environment Details (AEM version/service pack, any other specifics if applicable): Customer-name/Organization name: Adobe & serveral customers using App Builder extensively Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: Developer Console in AEMaaCS should display runtime environment variables values too - This helps to know which is the current value being picked (default or custom) Use-case: Currently the config.json displayed in the pod at cloud manager for an instance displays configuration for environment variable as is in the codebase - "configKey": "/configValue/$[env:CUSTOM_KEY;default=9876543210]/rohan", If the CUSTOM_KEY is configured in environment variable then the value that should be displayed is the actual one and not the above one. If it's not configured then the default value should be displayed to give a better idea of whether an environment value is configured for an instance or not. Current/Experienced Behavior: User has to navigate to the Environment Variable console to manually verify whether CUSTOM_KEY is configured or not. In a project with 150+ env variables this becomes an unnecessary lookup. Improved/Expected Behavior: The config should display the proper correct value. If no environment value is configured then display the default one else display the custom one. Environment Details (AEM version/service pack, any other specifics if applicable): 2024.10.18311.20241017T104455Z Customer-name/Organization name: EPAM Systems Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: The Cache metrics report generated by Adobe SME named "AEM CS BPO Tech Staff Report.pdf" monthly basis recommends improving the CDN Cache ratio but the way its generated needs to be revisited as the internal call, or URL forwarding requests, internal redirects are all being tracked differently causing the cache hit and coverage ratio scores reported low. Use-case: Ex: when the request is made for our website like fiserv.com gets (302) redirect to https://fiserv.com and to https://www.fiserv.com/ in this case considered as different requests and reports miss or pass. As this is the homepage and the number of page visits to the homepages are high the score gets impacted significantly. other examples like A) there are calls like /autodiscover.xml and other that gets originated from network or bots or health checks and not from core AEM application which also gets reported as MISS/PASS and impacts the score. B) json responses with url params cannot be cached due to impl nature and requirements but this also gets reported as MISS After detailed manual analysis and cache coverage details the Adobe SME confirms we are on excellent coverage beyond the minimum standards and no issues but as per BPO report and score from Cloud manager dashboard we are not. Hence request for revisiting of reporting to reflect actuals appropriately. Current/Experienced Behavior: The Cache score is low Improved/Expected Behavior: The Cache Ratio should reflect the relevant and appropriate scores Environment Details (AEM version/service pack, any other specifics if applicable): AEM CS Customer-name/Organization name: Fiserv Screenshot (if applicable): Code package (if applicable):
Request for Feature Enhancement (RFE) Summary: We propose adding accessibility testing to the AEM Cloud Service Cloud Manager pipeline, providing a baseline assurance for compliance with the European Accessibility Act (EAA) and the Web Content Accessibility Guidelines (WCAG) 2.x. By embedding accessibility checks directly into the CI/CD process, this feature would enable proactive identification and resolution of accessibility issues, fostering a more inclusive user experience and aligning with industry standards. Use-case: Compliance with Accessibility Standards (EAA, WCAG 2.x):Ensuring compliance with the European Accessibility Act (EAA) and WCAG 2.x is critical for organizations operating in Europe or serving global audiences. Automated testing within the Cloud Manager pipeline would provide a baseline for meeting these legal standards, reducing the risk of non-compliance and associated penalties. Early Detection of Accessibility Issues:By running accessibility checks at each deployment, teams can catch issues as they arise in the development lifecycle rather than after the website has gone live. This proactive approach enables timely fixes, reducing the effort and cost of retrofitting accessibility after deployment. Consistent Accessibility Checks Across Updates:Websites evolve over time with new content, features, and design updates. Automated testing ensures that accessibility remains a consistent focus, regardless of these changes. Testing at each deployment helps maintain high accessibility standards without relying solely on manual checks. Enhanced User Experience for All Audiences:Regular accessibility checks improve the overall user experience, particularly for users with disabilities. By identifying and resolving barriers to access, organizations can create a more inclusive experience that caters to all users, increasing engagement and satisfaction. Real-Time Visibility into Accessibility Status:Integrating accessibility testing into Cloud Manager provides real-time feedback for each deployment, helping teams monitor the site's accessibility status over time. This visibility allows for better tracking of improvements, trends, and issues, fostering a culture of accessibility awareness. Reduced Dependence on External Tools and Manual Processes:Teams often use separate tools or manual processes for accessibility testing, which can lead to inconsistencies and require additional setup. Having accessibility testing directly within AEM Cloud Manager centralizes this process, reducing dependency on external resources and making it easier to manage compliance in a unified way. Quick, Actionable Reporting for Developers:Axe DevTools CLI provides actionable insights into specific accessibility issues, helping developers understand and fix problems more efficiently. Integrating this into Cloud Manager would give development teams immediate feedback on violations, with clear paths to resolution, accelerating the remediation process. Simplified Audits and Documentation:Regular automated testing creates a log of accessibility compliance that can be used for audits, internal reviews, or reporting to regulatory bodies. With consistent testing and reporting, organizations can better document their commitment to accessibility and provide proof of compliance if needed. Improved Cross-Functional Collaboration:Accessibility compliance often involves collaboration across teams, including developers, designers, and content authors. With a centralized testing system in Cloud Manager, different stakeholders have easy access to results and can work together to address issues, fostering a more collaborative and inclusive approach to accessibility. Optimized Resource Allocation for Accessibility Work:Automated testing helps teams identify which pages and components are non-compliant, allowing them to allocate resources more effectively. For example, developers can prioritize fixes on the highest-traffic pages, ensuring that accessibility efforts are strategically focused on areas with the most impact. Simplified Enablement of Accessible Design Practices:Regularly surfacing accessibility issues through automated testing encourages teams to design and develop with accessibility in mind from the start. Over time, this helps build a team culture that prioritizes accessibility, reducing the frequency of issues in future releases. Risk Mitigation in High-Visibility or High-Risk Deployments:For major releases or updates to high-traffic pages, automated accessibility testing provides an extra layer of assurance that all users will have a positive experience. This is especially important for key marketing pages or campaign launches, where accessibility oversights could negatively impact a large audience. Simplified Accessibility Compliance for Multiple Geographies:Many organizations operate in multiple regions, each with different accessibility standards. Automated testing within Cloud Manager can help ensure compliance across various legal frameworks by testing for standards like WCAG 2.x, reducing the risk of non-compliance regardless of location. Current/Experienced Behavior: Adobe Experience Manager (AEM) Cloud Service currently does not include built-in accessibility testing as part of its Cloud Manager pipeline. Accessibility compliance checks are often handled through external tools or manual processes, resulting in potential inconsistencies and increased risk of non-compliance with standards like WCAG 2.x and EAA requirements. This can make it challenging to maintain consistent accessibility standards across updates. Improved/Expected Behavior: We recommend integrating automated accessibility testing within the AEM Cloud Manager pipeline. This enhancement could use a solution like Axe DevTools CLI to conduct accessibility tests on either a set of pre-configured pages or the customer’s 20 most-visited HTML pages, provided the site is not headless. This would give developers a reliable way to identify accessibility issues within the CI/CD process, ensuring regular compliance checks and addressing issues early in the development lifecycle. Key benefits would include: Consistent accessibility testing aligned with WCAG 2.x and EAA standards. Proactive issue identification within the CI/CD pipeline. Enhanced usability for all users through improved accessibility compliance. Environment Details (AEM version/service pack, any other specifics if applicable): Customer-name/Organization name: e.g. VodafoneZiggo Screenshot (if applicable): Code package (if applicable):
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.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK