Product ideas | Community
Skip to main content

Ideas

Filter by idea status

10000+ Ideas

user01245Level 2

Ability to add custom design/styling to custom forms and request queues (i.e. font size, font weight, color, etc), also support WCAG 2.1 AA complianceNew

Description:I'd like the ability to have a little bit of control over the look and feel of custom forms, particularly how they are displayed when used as a request queue. Ideally we'd be able to adjust font size, font weight, color, bolding, etc.  Even if we could apply a default font-size for the form, and selectively bold some text, that would be a huge improvement. Additionally, a complaint I've received multiple times is that the font size for a question is smaller than the font size for an option within that question.  If we could change the font size we could fix this ourselves. Or, if it's easier, make the question font-size match that of the options below it.  Example: Why is this feature important to you -There are new rules that go into effect in April 2026 around accessibility of internal and external documents for Government agencies. All documents must be WCAG 2.1 AA complaint. Depending on your reading of the guidelines the current request queue forms may not be in compliance.  More information here:  https://www.ada.gov/resources/2024-03-08-web-rule/How would you like the feature to work -I can think of a few different ways to address this:1.) Allow admins to set a default font size for request queue forms and be able to selectively bold descriptive text in forms.2.) Give us complete control over the font size, color, etc, on a per-question basis.3.) As a stopgap, increase the font-size of the question label to match that of the options below it, and ensure request queue forms meet all other WCAG 2.1 AA guidelines.  Current Behaviour:We have no control over the design of custom form/request queue design, and current request queue forms may not be WCAG 2.1 AA compliant.

Action to move Workfront Documents into an AEM Linked Folder via WF Connector (or even HTTP request)New

Description - Please enable a way to us to automate the moving of regular Workfront documents (i.e. local in the Project) into an AEM Linked Folder via the API (preferably a Fusion action module).Why is this feature important to you - It's laborious and prone-to-error for users to manually drag and drop Workfront Documents into an AEM Linked Folder. We have many clients where this could be a big time-saver both in terms of reducing the effort to move files and also improving the accuracy of where they place them as we could automate that based on Document metadata.How would you like the feature to work -  Have a Workfront module in Fusion where we can map in the Document ID and also the ID of the (Linked) Folder or its associated Linked Folder ID it is to be moved into. Even if we have to use a Workfront Custom API call or plain old HTTP Request that would be fine as long as it is via a Production API.Current Behaviour - There are various internal API calls we have tried to emulate via Fusion and there is an experience league article from last year with a accepted answer post from @victorto2 (please note that the original question is not relevant...only the answer) which indicates it was possible at that time but I've been unable to get that to work yet. And, even if I did, it is an unsupported internal API call which is not ideal for production use by customers. So, basically there is no current workaround.

webera
weberaLevel 2

Provide OOTB Renditions to Asset Compute microservice extensibilityInvestigating

  Request for Feature Enhancement (RFE) Summary: Provide a way for the "Asset Compute microservice extensibility"/Asset Compute workers to access the default renditions for an Asset so the custom worker can use those as a baseline for further conversions. Either: Pass a default rendition to the worker (instead of, or in addition to, the original). Or: Defer worker invocation until default renditions are generated (opt-in), so the worker can fetch them reliably. Or: Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice Use-case: We need to generate custom renditions (e.g., square JPEGs with white borders) from assets like .ai (Adobe Illustrator), .psd (Adobe Photoshop), .svg, .eps, etc. These file types are already supported by AEM’s default rendition generation, but not by Asset Compute workers directly (see below for reasons). If workers could use AEM’s default renditions as inputs, they could reliably transform these assets without needing external tools. Current/Experienced Behavior: AEM Assets and the generation of (default) renditions already supports a wide range of file types. However, the "Asset Compute microservice extensibility" is fairly limited in the filetypes it can process. There currently is no way we and Adobe Support found to support mentioned filetypes (ai, psd, ...).There is no way of reliably accessing the generated (default) renditions which then could be used as a baseline for the actual conversion from within the microservice, as they are not generated at the time of invocation microservice Technical details/background: The "recommended" library "JIMP" which is referenced in the demo project is super limited in the filetypes it can support (currently only jpeg, png, bmp, tiff, gif) Using other image conversion libraries wasn't successful either, as they always rely on binaries (like imagemagick) which don't work on the ARM64 containers the microservice runs on As mentioned previously, trying to access the default renditions and using them as a baseline for the conversion doesn't work either, as they are not generated/available at the time of the invocation of the microservice In summary: Asset Compute microservice currently only works for a very limited set of filetypes. Improved/Expected Behavior: Three possible solutions (either would solve the problem): Allow default renditions or custom defined renditions to be passed into workers instead of only the original Asset binary Invoke custom workers only after default renditions exist (opt-in, via processing profile checkbox), so the worker can fetch and transform them. Allow non ARM64 containers and installation of custom binaries like imagemagick for the Asset Compute microservice Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud Service (2025.8) with Asset Compute microservice running on Adobe AppBuilder/Runtime) Customer-name/Organization name: (private), see support case E-001769596 for customer specific details Screenshot (if applicable): N/A Code package (if applicable): N/A

Workfront Global Search should return matches across the full dataset (not limited to the first 2,000 results / page)New

In large Workfront instances, Global Search / Advanced Search becomes inefficient because results are displayed in pages capped to a fixed batch size (e.g., 2,000 items per page). When an organization has thousands of objects (Projects, Documents, Users, Templates, etc.), searching for something specific may not appear on the first page—forcing users to manually click through multiple pages to find a known item. This creates friction for everyday navigation and slows down work, especially for admins and power users who need to locate records quickly. Workfront search is meant to help users “easily locate items” across many object types, but the current paging behavior undermines that goal at enterprise scale. Why this feature is importantTime savings & adoption: Users lose minutes per search when they must page through thousands of results, which hurts adoption and confidence in Workfront as the “source of truth.” Enterprise-scale usability: Many customers have 8,000+ projects/documents/users, and the search experience should scale accordingly. Reduces errors: Manual paging increases the risk of selecting the wrong object or assuming something “doesn’t exist” because it wasn’t in the first result set. Search is core navigation: Since search behavior already varies by permissions, missing items due to paging limits adds another avoidable obstacle.How I would like the feature to workOption A (Preferred – best UX): “Search first, then limit.”When a user enters a search term, Workfront should query the entire searchable index for that object type and return the most relevant matches even if they would have been beyond the first 2,000 items in the underlying list. In other words: apply the search filter to the full dataset first, then display results.Option B: “Show all results / larger page size.”Add a user option (or admin-controlled setting) to increase “results per page” (e.g., 2,000 / 5,000 / 10,000) or provide a “Show all matches” mode for searches.Option C: “Find within results across all pages.”If Workfront must keep paging for performance, add a “Search within results” that searches across all pages and jumps directly to the matching items—without the user clicking Next/Next/Next.(Any of the above would dramatically improve navigation for large environments. Current behaviorWhen searching objects (Projects, Documents, Users, etc.), the results are shown in batches (example: 2,000 per page). If the item I need is in page 2/3/4, I must manually navigate across pages to find it. This is especially painful when I already know the name/ID and just need Workfront to take me to the correct object quickly. Acceptance criteria (what “done” looks like)A search term returns results from the full dataset for the selected object type, not just the first batch. Exact matches (or strongly relevant matches) appear in the results even if the object would otherwise be beyond the first page. Users can locate a known object without manually paging through results. Performance is maintained (e.g., via indexing/relevance ranking), but completeness of matching is preserved. 

Selliers
SelliersLevel 4

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

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.

ChargotraLevel 3

Expose Archived Program Flag & Improve Program Membership API for Large-Scale InstancesNew

Hello Marketo Community, We are currently operating a large Marketo instance and are facing scaling challenges related to program membership data extraction via the REST/Bulk APIs.  Current Limitation At present:  There is no API-exposed field that identifies whether a Program is archived. Archiving a program in the UI (e.g., moving it to an archived folder) does not translate into a machine-readable “archived” flag via the REST API. The Program Membership Bulk API requires filtering by Program ID. There is no supported endpoint to retrieve program membership changes between two timestamps without iterating through individual Program IDs.  Because of this, integrations must iterate across all program IDs to ensure no membership changes are missed — even for programs that are long archived and no longer operational.  Business Impact For instances with thousands of programs:  API calls increase significantly as program volume grows. Sync runtimes increase over time, even if most programs are inactive. There is no supported way to exclude archived/inactive programs from recurring membership checks. This creates scaling and performance constraints for downstream data integrations and analytics platforms.   Requested Enhancements We would like to request consideration for one (or more) of the following improvements:  Expose an “archived” (or equivalent) boolean flag via the REST API This would allow integrations to safely exclude archived programs from ongoing membership syncs (assuming archived programs cannot have membership updates). Allow bulk program membership export without requiring Program ID filters For example, enabling exports based purely on time windows (start/end timestamps) rather than per-program iteration. Introduce an endpoint to retrieve program membership changes between two timestamps This would dramatically reduce the need to scan all program IDs during each integration cycle.   Why This Matters As program volume grows over years of usage, performance and API efficiency become critical. These enhancements would:  Improve scalability for enterprise customers Reduce unnecessary API consumption Improve sync performance for data warehouse integrations Enable better architectural patterns for reporting and analytics

Add an ability to "Replace a file" from the asset's properties pageInvestigating

Request for Feature Enhancement (RFE) Summary: Content managers need an ability to "Replace a file" from the asset's properties. We implemented an override for them (pictures attached). In future we'd like to have this feature as Out-of-the-box functionality. Use-case: Content manager creates an asset's language copy, then "Reveal in Asset", then goes to the asset's properties and need to Replace the original file by translated version of file, having stored it on local computer with different name. Current/Experienced Behavior: Content manager can update an asset's file by one of the 2 ways: Create a Version: Open the folder in the DAM. Find his/her asset file. Select it and click on the "+ Create" button, then select "Version" button. Replace an original file OR Create a version:Save a future image with the SAME name as an original asset's file in the DAM. Drag and drop the future image to the DAM. System suggests "Create a version" or "Replace". Improved/Expected Behavior: User Story: As a Content manager, I want to be able to "Replace a file" from the asset's properties to avoid walking through assets listing and files renaming.   Acceptance criteria: Content manager can update an asset's file from the asset's properties by uploading the file from his/her local computer. Content manager can choose 2 options: "Create version" or "Replace". If "Replace" option is selected, AEM saves the file to the same directory and automatically rename uploaded file to the same name as the original asset (original file is deleted). If "Create version" option is selected, AEM creates a version of the file (original file is saved). Uploading file with different extension than original asset is not uploaded and the error is displayed. The button "Replace file" is displayed on menu above asset properties page. Environment Details (AEM version/service pack, any other specifics if applicable): AEM Managed Services, v6.5.14 Customer-name/Organization name: Veeam Software Screenshot (if applicable): We implemented an override for Content managers: Code package (if applicable):