Build better products with our product team
Idea Summary: The new Cloud Manager Content Fragment (CF) Editor does not support displaying custom field types such as ColorField, TextArea, and PathField, which were previously replaced in the classic editor. This lack of support significantly impacts users relying on these customizations for structured content authoring. We propose adding native support or a UI extensibility option to render these field types appropriately. Business Use Case: Organizations using AEM depend on custom field types to maintain structured content entry consistency. The inability to render these fields in the new CF Editor forces users to revert to the classic editor, limiting their ability to leverage new UI features. Providing native support for custom client-side renderers would enhance usability and encourage migration to the new UI. Current Behavior: The CF Editor does not recognize or display custom fields such as ColorField, TextArea, and PathField. Custom client-side renderers are ignored, making values stored in these fields inaccessible. Users must use the classic editor to maintain content integrity, reducing the adoption of the new UI. Expected Behavior: Support for rendering custom field types within the new CF Editor. The ability to register and reference custom client-side renderers for field visualization. Improved UI extensibility to maintain parity with the classic editor’s capabilities. Steps to Reproduce: Replace a single-line text field with a ColorField, TextArea, or PathField. Open the Content Fragment in the new CF Editor. Observe that the field does not render as expected. Open the same fragment in the classic editor and see the expected rendering. Impact & Benefits: Ensures a seamless transition from the classic editor to the new UI. Improves content authoring experience by maintaining structured field visualizations. Encourages adoption of the new CF Editor without sacrificing customization. We appreciate Adobe’s continued improvements and request consideration for this enhancement in a future release. Thank you for reviewing this proposal.
Request for Feature Enhancement (RFE) Summary: a feature to let the user "pin" (save) a specific path on AUP as a starting point when choosing assets or content links within AUP. After pinning a location, next time the user has to browse to an asset or content element, the pinned location is used as a starting point. Use-case: when editing pages on elements such as: - content grids (articles, case studies) - content grids (people) - page configuration (selecting hero banner image, selecting featured image, selecting thumbnail) - configuring links (CTA buttons, text links etc.) Current/Experienced Behavior: Expanding the directory path from the starting point is very time consuming, and it needs to be done multiple times - Country branches are not sorted in a meaningful way, which makes it very difficult to find the needed folder in the directory tree Improved/Expected Behavior: Example scenario 1 (non-exhaustive of the use cases): In a content grid, the user clicks to add a new item. They click the folder icon which opens the content structure starting at the "EY Unified Site" level. The user finds the directory which they want to be the new starting point for adding content to content grids and they "pin" and save this directory location. Once this is enhanced, in content grid, when clicking the folder icon, it starts browsing from the saved (pinned) location. The user has the option to unpin the folder and pin a new one if needed. Example scenario 2 (non-exhaustive of the use cases): Similar thing happens in the Page Properties / Images tab, where the user defines the assets to be used as page thumbnail and featured image. The "Pick" and "Select image" links open a dialog window which starts at the pinned location for assets. Note : the pinned locations for assets and for content are different. The user can pin a location for each of the different use cases – for content fragments, for links, for images and for documents Environment Details (AEM version/service pack, any other specifics if applicable): 2025.1.19149.20250116T154450Z Customer-name/Organization name: Aneesh.KM@gds.ey.com / Hans.vinje@nl.ey.com / EY / EY.COM Screenshot (if applicable): NA Code package (if applicable): NA
We would like the ability to select two parents on a workflow stage, both needing to be approved before going to the child of the two.
Issue -The Layout Templates are a great way to tailor the user experience in the system. However, we use the system at an enterprise level with various tenants using the system using the Group setup. The problem is we have users that work with multiple groups in the system. The layout template assigned to them as part of their home group may not align when they are working on work objects from another group. For example, a User 1 in Group A may hide Business Case section of a project to meet their operational needs. However, User 1 may have to work on a project that is managed by Group B that uses Business Case. Because User 1's layout template hides Business Case, they cannot see the Business Case section in Group B's project. How would you like the feature to work -I would like layout templates differentiate between overall/default view of the system, and the context of the object they are looking at (portfolio, program, project, task, issue, team, etc.). This would probably involve defining the layout template at the group level so that all objects for that group inherit the layout. For example, if a user is part of Group A with a specific layout template that does not show Business Case, but they are viewing a Project that is linked to Group B where that group's layout template shows Business Case, then show the Business Case section.
Currently I can pull bot name as a dimension and bot pageviews as a metric in Analysis Workspace. And I can pull IP address or user agent in Data Warehouse. But I can't pull bot name or bot pageviews in Data Warehouse and I can't pull IP address or user agent in Analysis Workspace (at least out of the box) and breakdown bot name by IP. I would love the ability in either Workspace or Warehouse, (but ideally both), to be able to breakdown bot name by IP address/user agent, but right now there's not a great way to do that.Customer care confirmed this was the case.Here's a brief summary of our discussion for future references:You were looking to pull out bot reports in Data Warehouse. I informed you that its not possible as bots are excluded from the reporting. The Bot reports are only available in the Workspace and that too, separate from rest of the report suite data. Further, you wanted to enquire if its possible to pull out Bot Reports with IP Address or User Agent. Unfortunately, there is no reporting engine that will give us Bot data with IP Address or User Agent. I suggested to raise this in Experience League Community as a feature enhancement.
As customers utilize newer features within GTW, the use case for this feature will grow and it would ideal for the integration with Marketo to support this.
Description - The Job Role object appears to have the DATA_EXTENDABLE flag in the Workfront API. It would be very useful in the UI to allow custom forms/fields to exist on the Job Role object. Why is this feature important to you - Much of our organizational KPI metrics are based on Job Roles. As such, many of our Workfront reports use the Job Role as either a filter or a grouping depending on the report. To give some examples, our Job Roles can have different metrics like expected hours, anticipated performance goals, sustainability metrics, among other organizational-specific items. Right now, I have to pull Workfront reports out to Excel, and then cross-reference/VLOOKUP against my standard metric list before presenting the reports to leadership. A custom form/fields would allow me to display this data natively in a Workfront report/dashboard. How would you like the feature to work - Allow adding custom fields/forms to the Job Role object. Current Behavior - The modal for editing Job Role has only fixed fields, and does not allow custom fields.
Description - Make it easy to locate a particular folder using Graph API option in the documents section. Problem - When I search for a particular folder, it gives multiple results with the same name (making it difficult to go for the correct folder). In the example image below, I'm trying to search for 'Development' folder and there is no way for me identify the folder I'm looking for. Why is this feature important to you - I'm trying to introduce this option to Project Managers for them to use project documents effectively. How would you like the feature to work - Some way to indicate hierarchical name of the parent folder(s). Current Behaviour - No indication of hierarchical folder name(s).
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.