Build better products with our product team
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 -
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.
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 - 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.
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?
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.
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):
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.