Product ideas | Community
Skip to main content

10000 Ideas

AsiaSt-LoNew Participant

Plan an iteration check/uncheck stories on the Backlog tab in the New ExperienceNew

Description - The process of planning an iteration on the Backlog tab of the New Experience is not intuitive and causes a lot of problems when trying to respect a teams capacity when planning an iteration. Why is this feature important to you - Users must be able to easily see if stories selected exceed the total iteration capacity during the planning of an iteration in order to respect the teams capacity. This will also make it much easier for user to properly plan iterations without having to go back and forth through pages in Workfront. How would you like the feature to work - When a user wishes to plan/create a new iteration from the Backlog tab, the user can click on the "Plan Iteration" button and a new section appears above the list of stories. The user can enter the necessary iteration information (name, start date, end date, focus, capacity, and goal). The user can also see in the same section the total capacity available for the iteration (capacity x focus). The user can then go through the list of stories and check/uncheck work. If the user selects stories that exceed the total available capacity for the iteration, the stories that exceed are highlighted in red in the backlog. Bring back the previous Workfront behavior as shown in the video on the following Experience League page - Plan and create an iteration | Adobe Workfront.  Current Behaviour - When a user wishes to plan/create a new iteration from the Backlog tab, the user must first select work items, then click the "Plan Iteration" button. The "Plan Iteration" dialog box appears where the user can see if they have selected too many/little stories for the iteration (based on team capacity = total points). If the user has selected too many/little stories for the iteration, they must close the "Plan Iteration" dialog box in order to deselect/select stories.

Javiersd12New Participant

Ability to Assign Admin Permissions to GroupsNew

Description:Our organization manages user permissions centrally through groups in Azure Active Directory (Azure AD). These groups are synchronized with Adobe Experience Cloud, allowing us to efficiently allocate product and profile permissions based on group membership. However, currently, administrative roles such as Product Administrator, Profile Administrator, Support Administrator, and System Administrator can only be assigned to individual users, not to groups. This creates a challenge for organizations that rely on group-based permission management and automation.Why is this feature important to you:Managing permissions at the group level ensures consistency, security, and scalability, especially in large organizations. Assigning admin roles to groups means that when a user is added to or removed from a group in Azure AD, their corresponding admin permissions in Adobe are automatically updated. This reduces manual intervention, minimizes human error, and helps maintain compliance with internal access management policies. Without this capability, we are forced to manually update admin roles for each user, which is inefficient and error-prone.How would you like the feature to work:We would like to be able to assign all administrative roles (Product Admin, Profile Admin, Support Admin, System Admin, etc.) to groups, not just individuals, within the Adobe Admin Console. When a user is added to or removed from a group in Azure AD, and that group is synced with Adobe, the user should automatically inherit or lose the corresponding admin rights based on their group membership. This approach should mirror how product/profile permissions are currently managed via groups.Current Behaviour:At present, administrative roles in Adobe Experience Cloud can only be assigned directly to individual users. Group-based assignment of these roles is not supported, which complicates permission management for organizations using directory group synchronization.

MichaelSMN
MichaelSMNNew Participant

Bulk User Assignments by Project & Program (+Workload Balancer for Program)New

Does your organization run programs with multiple projects?   Are your project managers responsible for managing large volumes of projects at the same time?   Are you looking for an efficiency win?     I think most organization will say yes and could really benefit from this idea.   Idea:   Implement the ability to quickly and easily assign users to roles at not only the project level, but also on the program level which would then cascade to all associated projects.  Add a Workload Balancer at the Program level with ability to do Bulk Assignments relative to the cumulative roles identified in the associated projects. How could this work?   Expose the Workload Balancer on a Program which would allow ability to assign/override any user on any given project for a selected role.   If a Project Manager assigned a user at the Project Level, this would then subsequently override the Program Level assignment; there could even be an indicator carried up to the program level that indicates multiple users or the values as well for a quick display if desired.   Current Experience Challenge:   Project Managers must either manually assign users task by task, or potentially through bulk edit through sifting throught tasks, or by going to the Workload Balancer for every project.    We commonly are running 10-15 projects or more and this requires a very significant amount of time every week to simply assign the same user. 

kwangmin11Employee

Cloud Manager : Enabling Rollback from Previous Build SnapshotsInvestigating

Request for Feature Enhancement (RFE) Summary: Cloud Manager Deployment: Enabling Rollback from Previous Build Snapshots Use-case: The customer is trying to roll back the deployment after a successful production deployment. Currently, the only way to roll back is to re-deploy the code in Cloud Manager, which takes 2 to 3 hours. Given that they are supporting 24 websites (with more to come in the future), they need to reduce the build time for any rollback operations. The best way to achieve this is to enable re-deployment using an earlier stable built image. Current/Experienced Behavior: The production deployment is completed. After the deployment, the customer discovered blocker issues on one of the 24 websites. They decided to roll back the deployment. They reverted the change that caused the issue and pushed the revised changes to Cloud Manager. They restarted the Stage/Prod build, which took 2 to 3 hours. The customer is trying to minimize this 2 to 3-hour downtime as much as possible. Improved/Expected Behavior: The production deployment is complete. After the deployment, the customer discovered blocker issues on one of the 24 websites. They wanted to roll back the deployment. They should be able to restart the Stage/Prod deployment using an earlier stable built image. Environment Details (AEM version/service pack, any other specifics if applicable): AEM as a Cloud (2024.4.16145.20240430T082417Z) Customer-name/Organization name: LG Electronics, Global HQ Korea 24 subsidiaries (UK,DE,PE,TR,JP,FR,SG,CO,SA,SA_EN,CA_FR,CA_EN,KZ,ID,IT,CL,TH,PT,IN,HK,HK_EN,BR ,MX ,PA) Screenshot (if applicable):   Code package (if applicable):