Product ideas | Community
Skip to main content

10000 Ideas

Selliers
SelliersNew Participant

Keeping the email content when changing template/design on your emailsNew

In our daily work we are facing a challenge when it comes to maintaince of email templates build from fragments. We are using different pre-defined templates that is built from fragments. And the fragments again contains just dummy images and lorum ipsum texts. The users changes the content in the fragments when they create there Journeys with there emails. The issue we are facing is when a content designer wants to change the template that is in use in an running Journey – there will be a problem. The content designer could have ordered a total new template, with a new look that he wants to use (a new framwork) or simply just want to change to another existing template (could be seasonal variations in the design). When you use the “change design” feature in the email, and changes to another template – you use all your created content in that email you are changing design too. It should have been possible to keep your content when you change the underlaying template.Maybe it could be solved buy having a export content feature, that takes all HTML code from the “Drag and Drop” container, and make this possible to import into the new template you have selected. The code is there, it is just to move it into the new selected template -and store it. That could have been an option when changing the design – move the content true or false, when you make your change.With an option like that it would be much easier to play around with templates and make changes seamless without any boundaries or risking loosing your created content by mistake.

NitaYaNew Participant

Ability to search for images in the “Pick Image” window (Image component)New

Request for Feature Enhancement (RFE) Summary: Ability to search for images in the “Pick Image” window on the image component   As of now, when an author tries to select an image using the “browse for image” option in components or page properties, they need to drill through the entire AEM directory and hunt for the image they want with truncated file names and tiny thumbnails. Could we have the ability to search for an image using file names or descriptions? Use-case: Image Search in “Pick Image” Dialog Currently, when authors select an image in AEM through the “Browse for Image” option (in components or page properties), they must manually navigate through the entire directory structure. This process is inefficient and error-prone, especially when dealing with large repositories, truncated file names, or small thumbnail previews. By adding a search capability within the “Pick Image” dialog, authors could quickly locate assets by file name, description, or metadata. This enhancement would significantly improve the authoring experience by: Reducing the time spent searching for specific images Streamlining content creation and updates Minimizing manual navigation errors Increasing overall productivity for large-scale content teams Current/Experienced Behavior: When we select/pick an image into the image component, we have to select the aem directory and hunt for the image we want  Improved/Expected Behavior: Could we have the ability to search for an image using file names or descriptions and then select the one we want Environment Details (AEM version/service pack, any other specifics if applicable): AEM 6.5 Customer-name/Organization name: OneTrust Screenshot (if applicable):   Code package (if applicable):  

lutzUNew Participant

Translation | Exclude jcr:title as default value when you are using option "Enable Content Model Fields for Translation" optionNew

Request for Feature Enhancement (RFE) Summary: Remove Content Fragment jcr:title from being included for translation by default when using option "Enable Model Fields for Translation" Use-case: For translation rules for CF I don't want to maintain rules in the translation_rules.xml file, instead I want to give just the creator of the CF Model the chance to define which fields should considered for translation by setting the field "translatable". With current situation creator of CF Model does in fact have NO full control as jcr:title is always translated (creating costs for translation that I do not want to pay. Hence feature is useless as I need to maintain my translation rules manually.  Current/Experienced Behavior: Even if I use the option "Enable Content Model Fields for Translation" to use the Translatable field of the Content Fragment Model in order to control which fields should be translated, the jcr:title of the CF is in by default. I can not exclude it and therefore is creates unnecessary costs. This makes no sense, as on the one hand you handover the control for translatable fields on creator of the Content Fragment Model, on the other hand you define the jcr:title to be translated by default with no option to control. See: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/administering/reusing-content/translation/rules# Improved/Expected Behavior: Remove CF jcr:title from being translated by default and give creator of CF Models FULL control over fields to be translated. Actually it makes no sense to translate the jcr:title of a CF as it makes more sense to keep this in one language (English) for common readability in AEM UI. 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):  

DougMc4New Participant

Make the Group Predicate Available in the AEM UINew

Request for Feature Enhancement (RFE) Summary:   Use-case: Summary:Walmart data custodians continue to expand our metadata usage within AEM Assets, and it is necessary to reflect those metadata fields in custom search forms. Currently, adding new metadata fields to the custom search interface requires code-level updates, as we are using the Group Predicate option to consolidate search facets into a dropdown. This slows down iteration and limits the ability of administrators to maintain and evolve search functionality in step with schema updates.   Current/Experienced Behavior: The Group Predicate (dam/gui/coral/components/admin/customsearch/searchpredicates/grouppredicate)—which is essential for logically grouping and structuring search filters—is not available through the AEM interface for manual configuration. While this predicate can be added through code, it cannot be added or preserved directly through the UI, leading to our business admins not being able to directly change the search form. Improved/Expected Behavior: Requested Enhancement:1. Make the Group Predicate Available in the AEM UI Users can add filters within group predicates Administrators can specify the title of the group predicate in the UI. The search form editor interface allows admins to specify whether the group predicate is initially open or closed for users. Environment Details (AEM version/service pack, any other specifics if applicable):   Customer-name/Organization name: Walmart US Marketing Screenshot (if applicable):   Code package (if applicable):  

Selliers
SelliersNew Participant

Auto update a journey expressions when an existing audience name is updatedInvestigating

We have experienced that expressions with audience names in the expression is not updating if the audience is changing name. This causes the expression to fail. since the audience "is no longer there". This causes problems for the users of the platform and the customers receiving communication. In bigger organizations like ours there are many different teams working in AJO at the same time, also in different countries. If there is an audience library to be used of many users, as part of staying under the audience threshold limitation, many user can use the same audience for different kind of activities. Both as inclusions, as well as exclusions in the organizations activities. And many will therefor also have the same audiences used in expressions. We see that this now causes big and surveil danger in using expressions in AJO Journeys. An audience name can easy be changed, planned or by mistake. And the consequences can be big when expressions then stop to work as planned, only because of a name change. The changer of the name might not even be ware of all the Journeys where this audience name is been used. Backtracking this can be a though and hard job, finding all the logical breaks that now has has come. We suggest that there is "another" connector in the expression builder that uses the ID for the audience rather than the name. Relaying on a name is not a good idea in general. You can showing the name in the creator, but in the back is should really be an ID that is used, something stable and reliable that doesn't change regardless of name and content of the audience. This discovered weakness can cause surveil damage to our customers, without anyone knowing.    

Selliers
SelliersNew Participant

PreFix possibilities in naming of audiences, Journeys and offers etcInvestigating

In bigger organizations with many users that uses AJO if can be difficult to make all use a common naming convention to structure the content created in AJO, like audiences, Journeys and offers. Even if we have the folder possibilities it is a good thing to have a good naming convention when searching or navigating trough the content. Even all know and understand this importance, it is hard to make all users follow this in there hectic daily work. The idea is to have the possibility to create a set of PreFixes of names that you as a user can use when creating content. F ex you just select the name of the PreFix by selecting it with a checkbox or from a dropdown, when creating things. When saving the PreFix will then be saved as the first part of the name of the thing you create. If you have operations in different countries you might want to have a country PreFix, in addition to f ex the department you work in. A set of naming PreFixes could then be f ex.No_SalesSE_SalesDK_SalesNO_SupportSE_SupportDK_SupportWhen creating audiences, Journeys or offers you select on of this PreFixes that will be part of the final name. As a user you can f ex name your audience "missed incoming calls oct 2025". The final name in AJO will, with the PreFix be: "NO_Support - missed incoming calls oct 2025" Now all users can from the name see and understand that this audience is not just about missed calls, but it is in Norway and it is missed support calls. This can off course be solved manually by having this as routines for all users. But as we all know it is hard to get all to follow routines like this, especially when resources coming and going over time. Therefor it would be a great feature to be able to administrate something like that from the tool itself.