Build better products with our product team
Request for Feature Enhancement (RFE) Summary: The Preview environment should be in Sync with the Publisher, to be able to preview the changes and see only the needed modifications. At the moment, AEMaaCS relies on the publishers to replicate the changes to both environments (Preview and Publish) this could lead into errors, leaving the Preview environment out of sync and breaking the purpose of it. The request is to have a service running that triggers replication to the Preview environment as soon as one page gets published. Use-case: Improve usability of Preview instance since the publishers will see only the content modified Current/Experienced Behavior: The Preview and Publish instances relies on manual user input to be in sync (publish twice) Improved/Expected Behavior: Preview and Publish should be updated at the same time during replication Environment Details (AEM version/service pack, any other specifics if applicable): AEM SDK 2025.10.22943.20251009T135918Z Customer-name/Organization name: UBS Screenshot (if applicable): Code package (if applicable):
The existing time dimensions (day, hour, minute) in the DWH are not fine-granular enough for a few clients' use case.Therefore, they are collecting the user-timestamp in milliseconds in a custom prop as a workaround for this issue. But this workaround has some disadvantages:a) User timestamp collected in the frontend is local and sometimes incorrect (days or years in the future/past)b) For some server calls, the prop is not collected / missingc) This workaround depends on the data collection (server-side timestamp would be independent of front-end data collection).Can this be considered a possible enhancement, making the server-side hit timestamp available as a dimension in the data warehouse?With my basic understanding, since DWH is the post-processed data. Any data on the DWH is the outcome of the raw data.Hence, this particular enhancement should first be in the data feed because the current data feed shows second-level information.
We have got ourselves into a situation where we have made many revisions to rules/elements which we have not published and no longer intend to publish. What is live and what is in our elements/rules are very different and it is now very difficult to get back to a clean baseline within rules and elements. The only way to do this is to manually revert every changed rule/element to match the current live version - very time consuming and prone to error. Please can you consider introducing a way to quickly update multiple elements/rules to match the live version?
Description - it is currently too cumbersome to commit to a new date. Users have to open the task to commit to a new date.Why is this feature important to you - users commit to new dates often so streamlined functionality is importantHow would you like the feature to work - from the My Tasks widget, open the summary area under quick actions and see the commit date field. OR have a commit date field as a column in the My tasks widget. Current Behaviour - Users have to open the task and select a new date from the commit date field.
Today in MSI our sales team can create modified list views for Best Bets using basic "AND" statement logic . In many cases the team would like to be able to configure this list using more advanced logic such as "OR" statements and logic groupings. A AND (B OR C)
Companies typically update exchange rates annually. At present, Workfront does not support multi-year exchange rates. For instance, revising the exchange rates for FY25 impacts the financials of projects completed in FY24 and prior. While this may not influence projects with minor budgets, it becomes significant for those with larger budgets.Request: Implement custom exchange rates that include a year parameter.
Currently in the New Request Experience Beta when you filter by status (see first screenshot below), the options are:CompletedIn ProgressRejectedIn reviewPending ReviewOut of these statuses, we only use Completed and In Progress, and there are many statuses that we use that are missing. Additionally, new Requests are shown as "In Progress", even when the Requests are not yet in an In Progress status. This causes confusion for our users when there is a status mismatch between the Request itself and the Requests page. See the example below in screenshot 2 and 3 where it shows my test request as "In Progress" on the Requests screen, but when you go into the Request, the status is "New". Ideally, the filter options for the Requests page would include all of the active Issue status options, similar to what is available when filtering Issue status in a Report. The status shown in the status column on the Requests page should match the status that the Request is currently in. Description -Why is this feature important to you -How would you like the feature to work -Current Behaviour -
Description - Currently document proofs open in a new tab. We'd like for document proofs to open in the same tab. This feature is important to us because our team frequently opens and reviews proofs and they would like to toggle between the project and the proof in the same window. Proofs opening in a new tab is creating excessive amounts of open tabs for the team. Thank you
When submitting a Adobe support ticket there is a selection of 129 time zones to choose from and it is difficult to find the one I need. There is a lot of scrolling through this long list because they are in not in alphabetic order. Perhaps you could offer up time zones in an easier way to navigate when submitting a ticket. Even better, having the system remember what I selected last time or what is linked in my profile would make this a much easier experience.
This idea proposal addresses a critical data integrity and reporting inconsistency in the existing Journal Entry Report related to Date custom fields. The report currently fails to correctly apply the user's time zone offset, resulting in dates that are one day off from the actual user-entered value displayed elsewhere in the platform. Description - The "New Date Value" column in a Journal Entry Report tracking edits to a Date-Only custom field (i.e., not a Date/Time field) often displays an incorrect date. This date is shifted by the user's UTC offset, resulting in a day mismatch compared to the date displayed in the Custom Form and the System Activity Log. This inconsistency arises because the report is not correctly translating the stored UTC date (which defaults to 12:00 AM UTC) into the viewing user's local time zone, causing the date to prematurely roll over to the previous day. Why is this feature important to you - Accurate reporting is fundamental to trusting a work management system. When a foundational report displays data that contradicts what's seen on the project itself and in the official activity log, it severely erodes user confidence and creates significant administrative overhead.Data Integrity and Trust: Contradictory dates force our teams to manually verify every data change, slowing down audits and governance processes. We need a single, reliable source of truth.Administrative Burden: The current workaround involves manually adding a text mode expression (ADDDAYS({}, 1)) to every single report column for every relevant Date field. This is not a sustainable or scalable long-term solution.Risk of Error: A manual offset workaround is fragile. It will break if users in other time zones view the report or if local time zone rules change (e.g., Daylight Saving Time shifts), introducing a high risk of new reporting errors.This is a request to fix a systemic design flaw (as acknowledged in support feedback) that prevents the Journal Entry Report from displaying the correct user-entered date consistently across the platform. How would you like the feature to work - The Journal Entry Report must be updated to apply the user's time zone offset to Date-Only custom field values consistently.Specifically:The date displayed in the "New Date Value" column must exactly match the date the user entered on the Custom Form and the date recorded in the System Activity Log.The system logic for the Journal Entry Report should be aligned with the logic used by the Project Custom Forms and the System Activity Log when displaying Date-Only custom fields, ensuring all three views show the same, correct local date.This fix should be system-wide and automatic, requiring no text mode workarounds or manual configuration changes by administrators for any Journal Entry Report. Current Behaviour - When a user in a time zone with a negative UTC offset (e.g., Central Standard Time, UTC-6) enters a date (e.g., 10/30/25) into a Date-Only custom field:Custom Form: Displays the correct user-entered date (10/30/25).System Activity Log: Records and displays the correct user-entered date (10/30/25).Journal Entry Report (in "New Date Value" column): Incorrectly displays the date as the UTC-adjusted date (10/29/25), shifting the date by one day due to the 12:00 AM UTC default crossing the day boundary in the user's local time zone.
Currently, the closest thing in Fusion to a Loop is the Repeater Module with hardcoded i and n variables. A loop module in Workfront fusion is greatly needed with the following capabilities.Ability to set i and n for loop.Ability to update i real time during loopAbility to escape loop once case is metAdding all types of loops... for each, do while etc. would be a home run.Fusion 1.0 had this type of logic and hoping we can get some of it back again.Current functionality does not allow for escaping the loop when certain condition is achieve so the loop is optimal. Now we are forced to indicate the number of iterations to a max number which is suboptimal from a processing point of view.
Description -While working in the source workspace, I've noticed two key usability gaps that affect data management efficiency:1. Missing Date-Based Sorting/Filtering.Currently there is no option to filter or sort files on a source folder by their date of availability or uploaded time.This make it difficult to locate newly available files or track which data arrived most recently -especially when the number of files is large.Adding a simple date filter or filter (e.g: Last 7 days, 30 days or custom range) would make it much easier to ingest files or validate latest ingestions.2. Dataflow Filter Performance IssuesThe existing filter under Dataflows is slow to load and often returns incomplete or inaccurate results.Optimizing the Dataflow filter logic and improving response times would significantly help teams manage multiple dataflows and save time.Why is this feature important to you -Easier identification of newly uploaded data to ingest.Faster and more accurate Dataflow managementOverall improvement in user experience and operational efficiency for AEP users handling larger datasets.
Description - Ability to in-line edit External Lookups with dependencies on list views. Curently we are able to edit fields that do not have dependencies.Why is this feature important to you - This is important because since the field is working fine on a custom form, it should essentially work on the list view as well. Having the ability to edit the field but restricted due to a technical limitation is not a great user experience.How would you like the feature to work - Ability to in-line edit External Lookups with dependencies on list views. The external lookup field should be able to process the URL with dependency on any other field.Current Behaviour - Curently we are able to edit external lookup fields that do not have dependencies I referred to this post: Custom forms: External Lookup – Usage in Views & F... - Adobe Experience League Community - 637209 and looks like the last update, to edit external lookup fields inline, was made last year. I think it has been way too long to keep this feature from the end users. To completely implement editability of External Lookup fields, this Idea needs to be implemented.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.