Build better products with our product team
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 - While using the HTTP Fusion module with the Basic Auth feature, the system creates a key (in the Keys section) for the credentials added. There is no option to update an existing key which was created in a case where the credentials were changed. We use many such connections to our internal services where the credentials are rotated periodically and to update them in Fusion, someone needs to find the usage of the credentials in the whole list of scenarios and update them manually after creating a new key.Why is this feature important to you - It takes a lot of manual effort to find and update every scenario, even with the use of the connection switch tool within the Fusion dev tools where a person needs to look through all the scenarios and update the HTTP modules.How would you like the feature to work - It would be nice to have an option to update an existing key from the Keys section where the users cannot see the existing credentials but are able to provide and save new ones. With that, the system should be able to switch to new credentials on every scenario instead of needing to do it manually.Current Behavior - The system only allows you to delete an existing key, and not update it. To change a credential for an HTTP module, the user has to create a new one and update all the scenarios manually.
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.
We don't worry about the time of due dates. We've always looked at end of the day as the deadline. Yes, sometimes we have to stay late to get it done on time. Now we have Workfront (in our 4th month) and the planned completion date has a time portion, which has cause some issues for us. Tracking On Time delivery, even 3 minutes past is considered late. We only worry about it going out on the date it was requested due. (We've worked around this with a custom field on a report, using the "cleartime" function, to get accurate reporting for our needs)We have two teams, one in Minnesota and one in Chile. We have a lot of issues with tasks and time off sliding up or down a day on the schedule because of the time zone difference. Makes for a scheduling nightmare! (we can work around this by setting every project and task due date to be ie. 5pm, but that's yet another tiny detail for our PM's to have to not forget) We'd rather not have to work around these issues. Could there be a global setting to "clear time" on all projects, tasks and issues?
機能改善要求（RFE）概要： We would like to be able to set the SameSite=None,Secure=Yes options for the saml_request_path (Cookie) configured in the "Adobe Granite SAML 2.0 Authentication Handler" ユースケース： I am performing SAML integration with the following configuration, but the value of saml_request_path (Cookie) cannot be obtained, so I am moved to the default destination after logging in. ・Uses "Adobe Granite SAML 2.0 Authentication Handler"・Configures two sets of Dispatcher-Publisher・Logs in on the IDP login screen after a period of time・Returns to the Dispatcher that did not send the request 現在／体験した動作： Cookies that do not specify the samesite attribute will become samesite=lax a few minutes after the cookie is generated.Therefore, saml_request_path (Cookie) created by another Dispacher cannot be read. 改善／期待される動作： Set SameSite=None Secure=Yes to always read saml_request_path (Cookie). 環境の詳細（AEM バージョン／サービスパック、もしあればその他の詳細）： AEM6.5(SP19) 顧客名／組織名 TDEN スクリーンショット（ある場合） コードパッケージ（ある場合）
Description: It's pretty straightforward: Make it so the status field is editable on the My Requests widget. Why is this feature important to you: We are on a crusade to remove clicks wherever possible. Right now, if I want to change a request's status in the My Requests widget, I have to select the issue in question, open the preview pane, and then change the status there. These are two additional clicks, plus it feels like the widget is broken. (That was my first thought.) Although it's not The End Of The World if one has to use the preview pane, I anticipate getting support tickets from people who think the same way I did. How would you like the feature to work / Current Behaviour: See above.
Description - Please add ability to either multi-select report suites, or add a bulk import for adding them Why is this feature important to you - Managing classification sets across many report suites is a PITA when you have to do it one at a time. How would you like the feature to work - Change the current UI from single rsid dropdown to be multi-select, OR, add new text area option to copy/paste list to bulk import / fill in fields. Current Behaviour - Report Suites can only be selected one at a time
Request for Feature Enhancement (RFE) Summary: Ability to disable the Publish functionality on Assets View Use-case: When using AEM Assets with Dynamic Media with OpenAPIs, the 'Publish' functionality is not relevant anymore as assets are published by 'approving' the asset. Current/Experienced Behavior: In an architecture based on Assets View and Dynamic Media with OpenAPIs, users see a Publish option, which is not supposed to be used. The Publish prompts occurs upon asset upload, which is confusing for the users. Improved/Expected Behavior: Ideally, there should be a configuration option to enable or disable the Publish feature depending on the the architecture needs. Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud Service - Assets View interface. Customer-name/Organization name: Screenshot (if applicable): Code package (if applicable):
Description: Enable sharing of request drafts, which is currently not possible in Workfront.Importance: Requestors save drafts to gather missing information or discuss with managers. Sharing drafts allows for manager input before submission.Benefits:• Manager review and feedback.• Team collaboration.• Departments add missing details.• Comprehensive review by all parties.• Stakeholder feedback. Desired Functionality: Add a "Share draft" icon to share drafts with internal team members.Current Behavior: Workfront allows sharing request queue links for direct submissions, but drafts remain private until submitted.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
