Product ideas | Community
Skip to main content

10000 Ideas

Selliers
SelliersNew Participant

Use of paragraph tag when pasting text into email fragmentsDeclined

We have discovered a strange ting that happens when we are pasting text into a fragment. If we are cleaning up the text in Notepad, and uses the text in a fragment we are running into some issues. It seems like if the text from Notepad has several paragraphs something strange happens. The first paragraph is recanalized as a paragraph and is placed inside a P-tag <p>.  But the other paragraphs that is pasted in is for some reason placed into div-tags <div> This causes problems with the design of the content. Explained in code this would look something like this:Notepad text:Here is our paragraph text oneHere is our paragraph text twoHere is our paragraph text treeIn our fragment in AJO the code for this would look like this: <p>Here is our paragraph text one</p><div></div><div>Here is our paragraph text two</div><div></div><div>Here is our paragraph text tree</div>As you can see the tree paragraphs are acting in different ways, one as a pragraph tag, the two others as div-tags. And it seems like there is used a div-tag to create line space between the paragraphs -where Notepad has space.This causes some problems with styling if you are using customized style classes since a p-tag and a div-tag isent the same thing - and in most cased has different classes. It would be great if pasting of plain text with several paragraphs could have the same tag conected to each of the parapraphs - like <P> is been used for all. 

HardikCharadva
HardikCharadvaNew Participant

Provide visibility for Leader Pod Restarts in Cloud Manager or SplunkNew

  Request for Feature Enhancement (RFE) Summary: Currently, Cloud Manager and Splunk dashboards do not provide visibility into leader pod restarts in AEM as a Cloud Service environments. Identifying when and why a leader pod restarts is essential for understanding system stability and troubleshooting potential performance or replication issues. Having this visibility directly in Cloud Manager (or accessible via Splunk logs) would help operations and development teams proactively monitor environment health, correlate incidents, and improve root-cause analysis without needing Adobe support intervention. Use-case: Leader pod restarts can affect replication, workflows, or cache invalidation, but currently there is no easy way for customers to detect or audit these events. Providing this visibility would reduce investigation time during incidents, enhance transparency, and empower teams to maintain stable AEM Cloud environments. Current/Experienced Behavior: There is no visibility or alert mechanism in Cloud Manager or Splunk for leader pod restarts. Customers must rely on Adobe Support to confirm such events. Improved/Expected Behavior: Display leader pod restart events in Cloud Manager’s monitoring section, with timestamps and pod names. Alternatively, include this information in the Splunk logs or provide an API endpoint to query pod restart history.Optional alerting mechanism (email or webhook) when leader pods restart unexpectedly. Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud Service – SDK version 2025.9.22758 (build: 20250928T092442Z) Customer-name/Organization name: Assa Abloy Screenshot (if applicable):   Code package (if applicable):  

sanjeevkumart45
sanjeevkumart45New Participant

One Content Fragment to manage all LanguagesNew

Request for Feature Enhancement (RFE) Summary: Improve multilingual content management in AEM by enabling a single content fragment to support multiple languages/locales through a tabbed or variant-based interface. Use-case: Our content authors manage over 500,000 content fragments across 12 languages. Currently, each language requires a separate content fragment, resulting in significant manual effort and complexity when performing routine tasks such as updates, moves, deletions, and publishing. Current/Experienced Behavior: AEM requires a separate content fragment for each language or locale. Authors must manually replicate actions (e.g., move, update, unpublish, delete) across all language versions. Shared fields must be updated individually in each of the 12 language-specific fragments. This leads to a high risk of inconsistency, increased maintenance overhead, and a time-consuming authoring experience. Improved/Expected Behavior: Enable a single content fragment to support multiple languages/locales using a tabbed or variant-based structure. Allow shared fields to be updated once and reflected across all language variants. Provide built-in tools or automation to manage language-specific content more efficiently (e.g., bulk move, update, unpublish, delete). Reduce manual effort and improve consistency across multilingual content. Environment Details (AEM version/service pack, any other specifics if applicable): AEM Version: 6.5 Service Pack: 6.5.22 Deployment:On-premise Content Volume: Over 1 million content fragments across 20 languages Customer-name/Organization name: Hyatt Hotels Corporation Screenshot (if applicable):   Code package (if applicable):  

NoahAn1New Participant

Enable “Approve with Changes” to Route Proofs Back to Creator in Workfront ProofingNew

DescriptionWe are requesting an enhancement to Workfront’s Proofing tool to allow greater flexibility in review workflows. Specifically, we would like the option for proofs marked as “approve with changes” to be sent back to the proof creator for updates before progressing to the next review stage.Why is this feature important to youSome internal teams currently use other project management tools because they offer more adaptable review workflows. The inability to send proofs back to the creator for updates after an “approve with changes” decision in Workfront creates challenges for teams that need to revise content before further review. This feature is crucial for meeting compliance requirements and would facilitate broader adoption of Workfront across our organization.How would you like the feature to workWe would like a configurable setting within automated proofing workflows that, when enabled, routes proofs marked as “approve with changes” back to the proof creator. The creator would then have the opportunity to make the necessary updates before the proof continues to the next reviewer. This should be an optional workflow step that administrators can enable or disable based on team needs.Current BehaviorCurrently, when a reviewer selects “approve with changes”, the proof automatically moves forward to the next stage in the workflow. There is no built-in option to send the proof back to the creator for updates first. Our only workarounds are either manually uploading a new version and adjusting the workflow, or creating multiple automated workflows for different scenarios, both of which add complexity and risk errors.

LauraHa12New Participant

Enable Manual Group Reassignment for Custom Forms in WorkfrontNew

DescriptionAllow users to manually update or reassign the Group associated with a custom form in Adobe Workfront after the form has been created.Why is this feature important to youAs a System Admin, I often collaborate across multiple departments and groups. Custom forms are a key part of our intake and project tracking processes. However, when forms are created by users in one group, they become locked to that group—even if the form is intended for broader use.  Being able to reassign the group would:Improve cross-functional collaboration.Streamline form governance and updates.Ensure forms are managed by the correct stakeholders.How would you like the feature to workI’d like to see a “Group” field editable by system admins or users with appropriate permissions. Ideally:The field could be updated in the form settings.A dropdown would allow selection from available groups.A confirmation prompt would warn about access changes or dependencies.Audit logs would track changes for accountability.This would mirror how other Workfront objects (like projects or templates) can be reassigned or shared across groups.Current BehaviorCurrently, the group is automatically assigned based on the home group of the user who created the form. The only workaround is to recreate the form using a user from the desired group, which is time-consuming and error-prone.