Product ideas | Community
Skip to main content

10000 Ideas

Pradeep-Jaiswal
Pradeep-JaiswalNew Participant

CJA Stitching(FBS/GBS) Visibility into Lookback Window, Replay Settings, and Scheduled RunsNew

Description -This feature would introduce a new settings panel within the CJA interface for stitched(FBS/GBS) datasets. This panel would provide clear visibility into the configuration and schedule of the stitching process, including the lookback window, replay settings, and the timing of data processing runs. Why is this feature important to you -Data accuracy and trust are fundamental to our analytics practice. Without knowing when the CJA dataset was last stitched or what lookback window was used, our stakeholders cannot be confident about which day of the week contains the most complete and accurate data. This ambiguity undermines our ability to make timely, data-driven decisions. It also creates an unnecessary dependency on the Adobe support team for basic information about our own data configuration. How would you like the feature to work -Within the CJA Data View settings, there should be a new tab or section dedicated to "Stitching Configuration". This section should clearly display:Lookback Window: The currently configured lookback window setting (e.g., 7 days, 30 days).Replay Setting: The status or configuration of the replay setting.Last Run Timestamp: The exact date and time of the last successful stitching run.Next Scheduled Run: The date and time for the next planned stitching run.Ideally, this feature would also evolve to allow administrators to not only view but also configure these settings directly within the UI, moving it from a "black box" to a self-service model. Current Behaviour -Currently, the configuration of the lookback window and replay settings for stitched datasets is a black box, managed entirely by the Adobe support team. There is no visibility within the CJA platform to see what these settings are, nor is there a way to know when the next stitching process is scheduled to run. This lack of transparency forces us to guess when the data is most accurate and requires us to go through support for any changes or information.

PolinaAbNew Participant

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):  

ManjunathaGNew Participant

Enable Hyperlinked Project Names in Team Request widgetNew

Description - The project name is no longer a link that will allow me to look at the project before assigning it to someone. That is something that used to be there, but went away with this recent fix.Why is this feature important to you - This feature is important because having the project name as a clickable hyperlink in the widget allowed us to quickly access project details before assigning tasks. It helped ensure we had the right context and reduced the chances of misassignments. Removing this functionality adds extra steps to our workflow and impacts efficiency, especially when managing a high volume of requests. Restoring it would significantly improve usability and productivity.How would you like the feature to work - We would like the project name in the widget to function as a clickable hyperlink, similar to how the task name works currently. Clicking the project name should open the project in a new tab or window, allowing us to quickly view its details without navigating away from the current page. This would help streamline our workflow by providing immediate access to relevant project information before making assignment decisions.Current Behaviour - In the current setup, only the task name appears as a clickable hyperlink in the widget. The project name is displayed as plain text and is no longer a link. As a result, users are unable to directly access the project from the widget, which limits their ability to quickly review project details before assigning tasks.

Raymundo2New Participant

Workfront External Lookup – Retrieve/Send Workfront Record ID & Details in WebhookNew

Description -When using external lookup fields in Workfront (e.g., dropdowns that fetch values from external systems via webhook), there's currently no way to know which Workfront object or record the user is editing or interacting with when the webhook call is triggered. This limitation hinders the ability to tailor results or logic based on the specific context of the Workfront record, such as a project, task, or custom form.Why is this feature important to you - As an integration architect working extensively with Workfront Fusion and other middleware platforms, we frequently design experiences where dynamic dropdowns should return context-aware results. For example, showing different vendor lists, funding sources, or templates based on the portfolio, project type, or requestor. Without knowing which Workfront record the user is interacting with, we are forced to build complex workarounds, cache lookups, or create duplicative forms, all of which introduce fragility and increase cost and implementation time. This change would enable smarter, more responsive external lookups and unlock a wide range of enterprise use cases.How would you like the feature to work - When a user interacts with an external lookup field and the webhook is triggered, Workfront should include the context of the record (e.g., record ID, object type, or other related metadata) in either the HTTP headers or the body payload of the webhook request. Ideally, this would be configurable so admins can choose to send fields like projectID, customFormID, or even specific custom field values (e.g., selected portfolio or request type) to allow for contextual logic in the receiving system or Fusion scenario.Current Behaviour - Currently, Workfront external lookup webhooks send no identifying information about the record or object the field is on. This results in a "blind" call to the external system with no context, preventing the use of record-specific logic, filtering, or validation in the external lookup response.