Build better products with our product team
Request for Feature Enhancement (RFE) Summary: We request the ability to set a password for public links shared via AEM Assets. This feature is essential for securely sharing sensitive assets in compliance with internal security policies. Currently, AEM does not provide password protection for shared links, posing a significant security gap. Use-case: Our mobile phone assets contain critical security data, and their distribution must be tightly controlled. However, the current public link sharing feature in AEM Essentials lacks proper security management.We are seeking a password protection feature to safeguard sensitive content—particularly assets shared at the headquarters level. Since these links are often shared with external design agencies who do not have AEM accounts, existing user governance is insufficient. All users with access to the link can currently view the content, which creates compliance and confidentiality risks. Current/Experienced Behavior: AEM Assets allows public link sharing but does not support password protection. As a result, anyone with the link can access the asset, with no additional security mechanisms in place. Improved/Expected Behavior: The ability to set passwords for shared links would align AEM Essentials with standard security practices supported by other cloud platforms. This would significantly improve asset security and access control. Environment Details (AEM version/service pack, any other specifics if applicable): AEM Essentials Customer-name/Organization name: Screenshot (if applicable): Code package (if applicable):
Description:In Adobe Target, once changes are made to an experience (e.g., offer content, audience rules, design tweaks in VEC), there is no built-in versioning or rollback functionality for that specific experience. If a mistake is introduced or someone wants to revert to a previously working version, it often requires manually redoing the changes or referencing screenshots or documentation - if available. Why is this feature important to you:Teams working on multiple activities across A/B tests and personalization campaigns need the ability to iterate quickly and safely. Mistakes can happen, especially in large organizations or distributed teams. Having a version history would reduce risk, support better collaboration, and speed up debugging and approval workflows. It’s especially useful for regulated industries or agencies where approval trails matter. How would you like the feature to work:Each experience within an activity should automatically store a version history whenever a change is made. This should include:A timestampThe name of the user who made the changeA summary of what was changed (e.g., audience modified, HTML updated, design edited)Users should be able to:View previous versionsCompare them visually or via a diff viewRestore a previous version with a single clickOptional: Allow notes/tags for major changes ("v1 approved", "client review", etc.). Current Behaviour:Currently, Adobe Target does not offer any version history or rollback capability. Once a change is saved and/or published, the previous version is lost unless manually backed up or documented outside the system.
Description –Managing Adobe Target activities often involves multiple roles across teams - marketers, developers, QA, and analysts. However, the current access control model does not allow fine-grained permission settings, making it difficult to delegate responsibilities securely and efficiently. For example, a QA specialist might need access to generate QA links but should not be able to modify offers or audiences. Similarly, a content editor might need to update offer text but not change targeting rules. The inability to configure such detailed roles leads to over-permissioned users and inefficient workflows. Why is this feature important to you –In large organizations or agencies managing multiple clients and campaigns, there is often a need to allow multiple team members to collaborate on activities. However, the current role-based access control lacks the flexibility to allow fine-tuned permissions (e.g., editing audiences but not offers, or managing QA links without publishing changes). This lack of granularity creates risk, slows workflows, and often forces teams to use shared credentials or workarounds.How would you like the feature to work –Adobe Target should provide customizable, granular access controls that allow admins to assign specific permissions to users or groups. For example:User A can create and edit audiences but cannot modify offers or publish activities.User B can update offer content but cannot change targeting or QA settings.A new "QA Reviewer" role can only view activities and generate QA links without edit rights.These permissions should be assignable at both the workspace and activity levels, and should support inheritance with overrides where needed.Current Behaviour –Adobe Target only offers broad user roles (e.g., Editor, Approver) that apply to entire workspaces. This often results in users having more access than they need, increasing the risk of unintentional changes or publishing errors. There's no way to restrict specific types of actions within an activity.
Request for Feature Enhancement (RFE) Summary: Enable authors to initiate workflows directly from the Content Fragments console in AEM, streamlining the content approval process. Use-case: Content authors often need to start approval workflows for Content Fragments. Currently, initiating a workflow requires navigating away from the Content Fragments console, which can disrupt the authoring flow. Use-case: Content authors often need to start approval workflows for Content Fragments. Currently, initiating a workflow requires navigating away from the Content Fragments console, which can disrupt the authoring flow. Current/Experienced Behavior: Authors must leave the Content Fragments console to start a workflow, leading to inefficiencies and potential errors. Improved/Expected Behavior: Introduce a "Start Workflow" action within the Content Fragments console, allowing authors to initiate predefined workflows without leaving the interface. Environment Details (AEM version/service pack, any other specifics if applicable): Adobe Experience Manager as a Cloud Service (AEMaaCS)/2024.03.12345.1 Customer-name/Organization name: Screenshot (if applicable): Code package (if applicable):
Description - Approvals should have a due date fieldWhy is this feature important to you - Many of the processes that require approvals in my line of work are timely and need to be received before certain activity can take place.How would you like the feature to work - I would like a due date field added to the approvals object to drive timely notifications when action is required and when. Example: A campaign (Project) has a list of drops (Tasks), with fixed start and end dates. A drop cannot occur until final approval has been received. I would want to set a Task Approval due date somewhere between 3-7 days prior to the set start date and have that trigger notifications to the Approver that they've been asked to approve and when we would need it, sending reminders as the due date approaches.
Description - I noticed that when users enter start time in Workfront (where the UI allows to specify time with up to a minute's accuracy), Fusion also adds seconds and milliseconds, which later leads to small discrepancies in processing.For example, when the user inputs the start time as 15:00 and the end time as 16:00, Fusion doesn't show 1h as would be expected after calculating the time difference but rather 0.9904197222222223h.I believe this is because 15:00 might be stored in the database as 15:00:01.500. Seconds and milliseconds can lead to subsequent inaccuracies in processing. Why is this feature important to you? Fusion gives inaccurate results when calculating time differences. How would you like the feature to work - fusion always zero out everything smaller than a minute, because UI doesn't allow for specifying anything smaller than a minute. Current Behaviour - Fusion silently and automatically modifies the time values as entered by users using the native Workfront .interface
I'm a Workfront system admin using the admin console. Recently, I created a test user account within the Workfront instance but then shortly decided to delete that account. I deleted the test account in the console and it was successfully removed. However, it has not been removed from Workfront itself. When I contacted support to see how to delete the account within Workfront, I was told there's no way to do that and that that's intentional because deleting a user account results in that user's history being erased. As an admin, I know it's best practice to deactivate an account rather than delete it permanently. But, as noted above, there are instances when an account, whether created temporarily for testing purposes or in error, serves no purpose and needs to be permanently removed. My recommendation is for the user deletion functionality be restored to admins who are using the admin console. Even better, it would be ideal to have the ability to delete users from within Workfront AND the console depending on where you happen to be deleting from.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.