Build better products with our product team
Request for Feature Enhancement (RFE) Summary: Introduce the Apache mvnd (Maven Daemon) wrapper in Adobe Cloud Manager so that the build step can reuse a long-lived JVM, parallelise module compilation, and dramatically cut cold-start overhead. This change targets only the build phase; the deploy phase likely remains untouched. Use-case: Large, multi-module AEM as a Cloud Service projects (often 10 + modules) can spend several minutes just starting Maven and resolving plugins for every pipeline run. In busy CI/CD setups (feature branch builds, frequent merges, scheduled quality gates) these wasted minutes quickly accumulate, slowing feedback loops and consuming CI minutes. Current/Experienced Behavior: Cloud Manager invokes the stock mvn CLI in a fresh container for each build. Each invocation spins up a new JVM, scans plugins, and builds modules sequentially. Typical build duration for a representative 10-module project: 9–11 minutes, of which ~1-3 minutes are Maven start-up and plugin scanning. Developers compensate by using mvnd locally, but must still wait for slower pipeline feedback. Improved/Expected Behavior: Cloud Manager containers start an mvnd daemon once, then execute build goals through the daemon for the lifetime of the build step. Parallel module compilation (default --threads=auto) and reused class-loaders remove the repeated start-up cost (potentially the resources of the build-pod(s) need to be increased to provide more CPUs to work with in parallel). Anticipated build-step time-savings: 25-40 % on typical AEM multi-module projects (confirmed in local benchmarks and community posts). No impact on deployment logic; output artefacts (all-, ui.apps, ui.content) remain identical. Environment Details (AEM version/service pack, any other specifics if applicable): ---- Customer-name/Organization name: ---- Screenshot (if applicable): ---- Code package (if applicable): ---- Maven-Deamon (mvnd): https://github.com/apache/maven-mvnd Article: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager-blogs/speed-up-local-development-in-multi-module-aem-projects/ba-p/738507
Occasionally, we have a situation where a lead is accidentally deleted or merged with the wrong record. When this occurs, we can restore most of the data including acquisiton program and date, program memberships with successes and dates, etc. However, we cannot restore the cookie association because the cookie ID is not exposed on the lead record (or its exported data). Please expose the cookie ID, so we can use the technique described by Jep in the Discussion item (Is there a way to reassociate a cookie with a lead record without the lead taking another action?) to reassociate their cookie with the restored lead record.
I've had a couple of clients now go to delete a My Token on a program only to be told the token is in use. Unfortunately there's no easy way to determine how the token is being used.This is increasingly important since tokens can now be added to Guided Landing Page templates and as long as the template is in place and approved it will prevent the deletion of the token.It would be nice to have a "Used By" column for My Tokens, just like any other asset in the design studio.
It turns out program tokens can be in use in very strange ways, which makes it a necessity to have the "used by" functionality for program tokens. A use case I came across today: Original token is set up in a campaign folder. Someone erroneously made changes to the inherited token in a program that was stored inside that campaign folder. The program with the incorrectly overridden token was then cloned to an entirely different campaign folder. The cloned program retained its reference to the erroneously overridden token in the source program. Therefore, when we tried to remove the token this was not possible as it was still in use. We needed Marketo Support to trace where that was, because in the UI it was impossible to figure out. Although it can be argued that the link to the original overridden token should be broken in the cloning, providing visibility on where a program token is used prevents this confusion already quite well.
It would be great to see a list of places throughout a program where your program tokens are being used.Even if there was some way to run an audit to do the same thing that would work as well.This would help to know if tokens are no longer being used or to see if there are any other places it is being used that are not initially apparent.
WorkFront has no ability to 'undo last action' - in some cases this can be very troublesome - as it is quite easy to make a change to basic project behaviour, critical path and end dates. An 'Undo' last change function would be very useful if the Project owner has in-advertantly made a change that has caused multiple activities to be impacted. Even a - revert to last saved version function might be useful - at least allowing the project owner to go back to a version that they have already reviewed and approved with their team.
Usually name of variables / metrics / segments, but also their value, are something really technical. That kind of values absolutely do not suit the needs of top management who cannot read technical description.Also, when we do complex workspace the name of column is hidden because no space available in layout. So, why dont allow to overwrite and change color of any string we have into column/row head or cell?
Description - Add field to capture the entry date of a report similar to the entry date of a issue, project, task, or user. Why is this feature important to you - This is important because I need to know how long a report has been available to be used. This helps tell the story of high quality reports that can be duplicated/copied for other users across my instance and peer customers of Adobe Workfront. If a report has been around for years and was recently modified that highlights importance and emphasizes need to secure it and have it monitored for quality control. The reports in Adobe Workfront are often used to drive key business decisions and knowing every aspect about a report is critical to data governance and management. How would you like the feature to work - Users should be able to add the field as a column (view), filter or grouping in similar manner as an entry date for a project, issue, or task. Current Behaviour - The field is not available in Workfront UI or API Explorer. @skyehansen
Description - The new calendar interface doesn't allow users to view as many rows as the old interface in each calendar day when in Month view. This is causing important information to drop off and have to be accessed by hovering over More.Why is this feature important to you - Our team prefers to have all items visible or at least be able to prioritize what they see.How would you like the feature to work - Allow them to reorder the items that appear in each day by dragging the important ones to the top of the list.Current Behaviour - Overflow tasks on each day default to More view and they have to hover over or click on them. The number of items also seems inconsistent. Some have 3 or 4 visible but others don't have any and default them to the more heading.
Description - Allow the option to hide the hourly breakdowns on weekly calendar view or expand the collection of calendar items in the top portion of the calendar Why is this feature important to you - We have many tasks that pull into a calendar view and the many tasks are now all scrunched together at the top. When the list is super long, a scroll bar appears and you can scroll within the tiny area. There is not a way to hide the hourly blocks below or expand the top portion to have better visibility into the items like the current/old calendar weekly view. How would you like the feature to work - Add a toggle button to hide the hourly blocks and/or a way to expand the top portion of the calendar to be able to see more items on the screen. Current/Old Behavior - New Calendar -
Please add the ability to grant to users view-only access to Admin sections. We need to grant to other users to see, for example, Report Suites's list and related information, variables, events and other useful sections, but this isn't possible at the moment - users with access to these areas automatically receive edit permissions.
Hi,when I create calculated metrics or segments for one data view, they also appear in other data views of my sandbox, if they are based on they use the same underlying schema. At first glance this looks good if you consider setting up a dev and prod data view and you only need to setup the calculated metrics and segments once. However, if the one data view based on which the calculated metric or segment was setup is modified or deleted, the calculated metrics and segments are not working anymore in the other other data view. Thus, it is required to setup the same calculated metric and segment in both data views. The issue here is that both calculated metrics and segments show up in each dataview in the workspace. However, for the analyst who creates a report the calculated metrics and segments of other data views are irrelevant.Please develop the option to show the calculated metric or segment only in the data view for which it was created. This would be much more user friendly.
Description -In Adobe Experience Platform's Event Forwarding, there is a requirement that OAuth2 tokens must have a minimum expiration time of 8 hours. However, the system we use internally for authentication only allows tokens with a maximum expiration time of 1 hour. This creates a compatibility issue, as we are unable to use our tokens with Event Forwarding due to this restriction. Why is this feature important to you -This limitation prevents us from integrating our internal authentication system with Adobe Event Forwarding, which restricts our ability to automate and scale our processes. Removing this requirement would enable us to fully utilize Event Forwarding in our workflows. How would you like the feature to work -We would like Adobe Experience Platform Event Forwarding to support OAuth2 tokens with expiration times shorter than 8 hours. Ideally, there should be no minimum expiration requirement, or at least support for tokens with a 1 hour expiration, which is standard for many authentication systems. Current Behaviour -Currently, Event Forwarding enforces a minimum token expiration time of 8 hours for OAuth2 tokens. Tokens with shorter validity periods, such as those generated by our internal system (maximum 1 hour), are not accepted by the platform.Configuring Secrets in Event Forwarding | Adobe Data CollectionDocumentation reference:An OAuth secret requires at least four hours between refreshes and must also be valid for a minimum of eight hours. This restriction gives you a minimum of four hours to intervene if problems arise with the generated token.For example, if the offset is set to 28800 (eight hours) and the access token has an expires_in of 36000 (ten hours), the exchange would fail due to the resulting difference being less than four hours.
The current 'Filter' in the Workload Balancer has limitation for the following functionalities whereby these are available in other objects type such as Projects, Tasks, and Requests.Select the Filter condition for "Include if all are true" or "Include if any are true". (Currently defaulted to ‘Include if all are true’ and not editable)Select 'Add Filter Groups' for filter operators 'AND' or 'OR'.Switch to Text Mode interface.It would be great if these functionalities to be made available in the Workload Balancer Filter to allow Resource managers to build complex filters for accurate resourcing.
Description - Have the ability to edit Shadow DOM elements using the HTML editor in the VEC, which is currently not supported.Why is this feature important to you -Many of our business users rely on the VEC, and adoption would significantly increase if this capability were available. It would reduce dependency on developers, save time and resources, and accelerate test launches.How would you like the feature to work - When you click on a Shadow DOM element in the VEC, have "Edit HTML" as an optionCurrent Behaviour - When you click on a Shadow DOM element in the VEC, "Edit HTML" does not appear
Description - For privacy and security, our org only gives access to the Resource Manager/Planner feature to a handful of Resource Managers. It would be great if team members, who do not have access to the Resource Manager feature, could self-serve and have access to a report that only shows their AVL, PLN, ACT and DIF values. Why is this feature important to you - With the lack of out of the box custom Resource Management reporting, team members have no way of seeing what their Resource Managers are seeing in the Resource Manager/Planner view. How would you like the feature to work - Update Resource Manager/Planner where when access is given to non Resource Manager team members, the system is configurable so that they are only allowed to access pre-made filters that have been shared with them. The filters cannot be updated or shared and will restrict what data they can see. Current Behaviour - Resource Managers/Planners are sharing reports with their team that display task/assignment planned hours and actuals in total and unable to replicate a weekly, monthly and quarterly view. It is not possible to mirror in reporting what the Resource Manager/Planner feature highlights with AVL, PLN, ACT and DIF. While you can currently report on a task/assignment planned hours and actual hours, these values are reported in total and not available to by week, month or quarter. If a task has a duration of two weeks and has planned hours of 10 days, today out of the box, there isn't a way to create a report that highlights that Week 1 has 5 planned hours and Week 2 has 5 planned hours.
Adobe should optimize Dynamic Chat by introducing a Live Chat option seamlessly integrated into dialogues, accompanied by a customizable scheduling feature for users to set specific time slots for live chat interactions.
Description -Add a dropdown field on the report configuration page that show what the report type currently is for the one being built and allow the different report types to be switched while building the report in the event that a project report actually needs to be a task report. This would keep the user on the page without having to go back to start a new report and enter in the report title again. This could also help limit the number of unused and/or unfinished reports in a customer's Workfront instance. Why is this feature important to you -Sometimes users select the wrong report type when starting to build new reports either by accident or by finding out that what they thought should be a project report should actually be a task report. This brings the need to close the report, go back to the where they can select a report type, and pick (hopefully) the correct one. I sometimes assist people on calls as they try to build out reports, and often times the root of the problem with the report not working or them not finding the fields they want to filter from comes down to them using a project report when they really need a task report. They get annoyed that they can't make a quick switch to a new report type without having to back out of the building the report. How would you like the feature to work -Feature a dropdown field on the report configuration page like the one when users start building reports that list the various reports types (project, task, issue, etc.) in the event that they need to change the report type while building because they find out that the current selection won't work for their needs. It's also an added visual so users can see what the report type is at all times. See attached image for an example. If not there, then may the dropdown could live within the Report Settings. Current Behaviour -Users have to back out of building the current report, click New Report, and select another option.
There is no option to accommodate a long string within the Program Member Custom Field object. A text area field would allow us to store URLs with long query parameters, lengthy content for personalization, and open-ended form responses within the program context.
I would appreciate a simpler way of adding screenshots into Analytics reports in Adobe Workspace to create more detailed and visually informative reports for stakeholders. At present, the only available method to embed an image within a Workspace project is by using a Text visualization, where you can insert an image through a hosted URL.
Description - Adobe to provide more access restrictions levels to CJAWhy is this feature important to you - I can restrict access to around 1000+ users who can potentially create reports with wrong dimensions and segments that would end up being shared across the company.How would you like the feature to work - to provide Read only access to stakeholders who has less experience with the tool and provide ability to change report suite/ Data ranges.Current Behaviour - We just have read only access or edit access. problem with read only access is that the user cannot change report suites or date ranges. That just limits them completely.
When you click to create a segment, you get a popup with "compose audience" and "build rule" options, with "compose" being the default pre-checked option. This makes no sense! Composed audiences is a limited feature, designed for advanced users, for specific use cases.I bet if you look at analytics, 99.9% of the users go to "build rule".I actually thought Adobe would fix this a couple of weeks after "compose audience" being released. This annoys me and is bad UX with a simple fix. Please Adobe, make "Build Rule" the default option.
Testing AEP mobile SDK analytics with a focus on which events are firing in the beacon.When trying to find the custom event# to validate the custom events are firing correctly, its extremely difficult to see them in amongst all the reserved evars. It would be extremely beneficial if we had to have all of these events shown then at least they could be alphabetically listed to be easier to read.
Request for Feature Enhancement (RFE) Summary: Request to have read-only fields in Context Aware Config to protect the integrity of the data Use-case: Sometimes we tend to store API keys or secret keys in context aware configurations for different markets to be used. So if we can create read-only fields in the CA config, then we can prevent someone from accidentally modifying it. Current/Experienced Behavior: Currently we can use String fields which are editable via authoring Improved/Expected Behavior: String fields with read only behaviour Environment Details (AEM version/service pack, any other specifics if applicable): AEM 6.2+ and cloud Customer-name/Organization name: Ramkumar Pandian Screenshot (if applicable): Code package (if applicable):
DescriptionCurrently, in Adobe Experience Platform, the creation and editing of datatypes are restricted to the method by which they were created. If a datatype is created via the API, it can only be edited using the API. Similarly, if a datatype is created via the UI, it can only be edited through the UI. This limitation creates an inconsistent and fragmented user experience. The requested feature is to enable cross-platform creation and editing, allowing datatypes created via the API to be editable within the UI, and vice versa. Why is this feature important to youThis feature is crucial for maintaining a seamless workflow between the API and the UI. Different team members and projects may have varying preferences or requirements for using the API or the UI. Restricting editing to the creation method adds unnecessary complexity, slows down development processes, and increases the risk of errors. A unified editing experience would enhance productivity, improve collaboration, and align with modern expectations for flexibility in software tools. How would you like the feature to work- A datatype created using the API should be fully editable within the UI, with all fields and configurations accessible.- Similarly, a datatype created within the UI should be editable via the API, using consistent endpoints and structures.- Ensure that the permissions and validations for datatype editing remain consistent across both platforms.- Provide clear documentation to explain the unified editing capabilities and any limitations. Current Behaviour- Datatypes created using the API can only be edited via the API.- Datatypes created using the UI can only be edited via the UI.- There is no option to switch between editing methods, leading to a fragmented and restrictive user experience.
Already have an account? Login
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.
Sorry, our virus scanner detected that this file isn't safe to download.
