Product ideas | Community
Skip to main content

10000 Ideas

andylunsford1
andylunsford1New Participant

Creating Shared Folders in Adobe Analytics Outside of Company FolderNew

Description Love the Company Folder and the ability to share a group of projects across your organization, but want to potentially share only relevant projects for users and / or want to hide non-relevant templates and folders?  Current state, the Company Folder is an all-or-nothing holding ground for placing reports and enforcing automatic sharing privileges.  However, there are situations where you want only a certain team or group of individuals (maybe even product profile) to access a certain folder or even see that folder.     I'm proposing the idea of allowing users to create a "Shared Folder" that will let you set-up your own sharing permission that allows you to create a project and move to the folder and all members of the group will be able to access, but will not have to give carte blanche access to all members of your company.     Why is this feature important to you I often have a team of core people I work with for certain projects or reporting focuses that allow for many reports to get created, or I have a list of 5-6 people who NEED to be shared a report, but it has to be reviewed and approved internally before it is shared out, and putting it into the company folder before it is ready is not an acceptable option. How would you like the feature to work Ideally, I would like the folder when selected on the landing page and the blue selection bar appears, it would have similar options to selecting a project, to "share", "rename", "pin", or "tag".  And inside the "Share" menu, you could manage the permissions for the folder similar to the pop-up menu that exists for projects: "Edit Sharing Access" could be used for determining who has the ability control access permissions for the folder, "Edit Project Access" would allow users to determine who could edit the projects inside the folder or move projects inside the folder, and "View Project Only" would allow users to be added to the folder to view reporting, but unable to edit (perhaps great for executives or others who you want to give visibility without risking a report getting unintentionally modified).    It could also be more complicated, and move to using product profiles if supporting this level of granularity inside the landing page wouldn't be possible, but the idea of allowing users to have folder permissions for storing their projects similar to the concept of Dropbox, Box, OneDrive shared folders is the core of the idea. 

William--
William--New Participant

Enable Custom Forms on Teams, Roles, Reports, and DashboardsNew

DescriptionWe have dozens of Roles, and hundreds of Teams, Reports, and Dashboards. The only tool that is built into Workfront to help us document and govern these objects is the Description field.  The absence of custom parameters on these objects is limiting in what and how we are able to document their usage.We would like to attach custom forms on these object types so we can spend less time tracking down all the people and places throughout our instance that are impacted by updates to these objects.This was enabled last year for other objects like Groups and Billing Records. The efficiencies gained by those enhancements should be further expanded to these additional object types. Why is this feature important to youIt is challenging to track and document governance-related details on these objects because we have only the description field to do so, and that field is exposed to all users. How would you like the feature to workFor Teams, Roles, Reports, and Dashboards, we would like to attach custom forms that we would design to help us in maintaining and governing those objects. Current BehaviourWe have only the Description field to add all details about these objects, so are constrained by space, format, and visibility to users.We have explored using Fusion to seed a collection of Projects and Tasks to add a lot of detail and metadata about these objects, but its tedious to maintain and isn't easily seen when someone is making updates to one of these objects. 

brianrieckNew Participant

Expose QA URLs in Adobe Target APINeed info

It would be nice to be able to programmatically access the QA URLs for a current running AB test.  We run a small subset of front end tests in our CI pipeline and we need the tests to be deterministic.  The way we do that now is manually retrieve the QA URL from the adobe target GUI.  We'd like to have the test determine the experience without having to retrieve the QA URL manually.   I have two suggestions:First:  Add it to the existing `Get AB Activity by ID` Second:  Create a new API to `Get AB Activity QA URLs by ID` Suggested response:    "experiences": [ { "experienceLocalId": 0, "name": "Experience A", "visitorPercentage": 34, "qaUrl": "at_preview_token=g5xKOs9QjAl3KN%2BwvyAAmnWEFq%2Br1NJA9GWwjZnLpb4%3D&at_preview_index=1_1&at_preview_listed_activities_only=true&at_preview_evaluate_as_true_audience_ids=1100025", "offerLocations": [ { "locationLocalId": 0, "offerId": 395818 } ] }, { "experienceLocalId": 1, "name": "Experience B", "visitorPercentage": 33, "qaUrl": "at_preview_token=g5xKOs9QjAl3KN%2BwvyAAmnWEFq%2Br1NJA9GWwjZnLpb4%3D&at_preview_index=1_2&at_preview_listed_activities_only=true&at_preview_evaluate_as_true_audience_ids=1100025", "offerLocations": [ { "locationLocalId": 0, "offerId": 395819 } ] } ]    If the qaUrl property is too verbose it can be broken up into its separate properties:at_preview_token, at_preview_index,at_preview_listed_activities_only,at_preview_evaluate_as_true_audience_ids

DanaRoNew Participant

Enable AI-Powered Document Upload to Auto-Populate Custom Form Fields in WorkfrontNew

Description - We would like the ability to upload a structured document (e.g., Word, PDF, linked SharePoint file) to a Workfront object (like a tactic or project) and have Workfront’s AI extract key data points and populate designated custom form fields. This would streamline the setup of records that rely on structured metadata already captured in offline templates. Why is this feature important to you - This functionality would eliminate redundant manual entry and improve data consistency across Workfront objects. It is especially important for our marketing team, which uses Workfront tactics to manage a content inventory. Each tactic has structured metadata that already exists in a completed Word template. Currently, this information must be copied and pasted into custom form fields, which is time-consuming and error-prone. How would you like the feature to work -Allow users to upload a structured document (e.g., .docx or .pdf) to a project, task, or tacticWorkfront AI parses the document and suggests values for mapped custom form fieldsAdmins can define mapping rules for which text fields in a document align to which custom form fieldsThe user reviews and accepts or edits the extracted field values before savingOptionally, allow mapping to vary by object type or custom form template Current Behaviour - Currently, documents can be uploaded or linked to Workfront objects, but there is no functionality to extract content from those documents and apply it to custom form fields. All structured data must be manually transcribed from the uploaded file into Workfront forms.

Melanie-Lynch11
Melanie-Lynch11New Participant

Auto-Clear Hidden Form Field Data When Option Is UnselectedNew

Description - We would like a more intuitive way for requestors to clear out data in irrelevant form fields when they change their selections in a request form. Why is this feature important to you - We want to eliminate confusion for requestors and prevent errors in automated processes and reporting. Currently, our Fusion scenario triggers messages based on a calculated field, and retained data from previously selected options can cause false positives. Requestors often believe they’ve submitted the request correctly, unaware that hidden fields still contain outdated data. How would you like the feature to work - When a requestor unselects an option, any data entered in fields associated with that option’s conditional logic should be automatically cleared. This would ensure that only relevant data is retained and reduce the risk of errors caused by hidden, outdated inputs. Current Behaviour - Our request intake form uses extensive conditional logic. Occasionally, a requestor will change their selection mid-submission or copy a previous request and modify it. When they deselect an option, the associated fields are hidden—but the data within them remains. This retained data can interfere with calculated fields and downstream automation, leading to confusion and incorrect outputs. I refer to this issue as the “ghost of a previous deliverable.” Despite efforts to educate requestors, many find it unintuitive that hidden fields still retain data. I’ve attached a tutorial video I created a couple years ago to demonstrate this behavior.

kwin1New Participant

Support wildcard DV certificates and subdomainsNew

Request for Feature Enhancement (RFE) Summary: Wildcard DV certificates and wildcard subdomains Use-case: For DEV and STAGE environments often a common publish domain is being used. As the default Adobe one (https://publish-pxxx-eyyy.adobeaemcloud.com/) does not allow subdomains the individual sites are addressed via subdomains of that common domain to have a similar setup as PROD (1 domain = 1 website). That allows even automatic mapping of content paths to sites without needing setup costs for additional sites. Current/Experienced Behavior: Cloud Manager does neither support wildcard domains in the domain settings (https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/using-cloud-manager/custom-domain-names/introduction#usage-notes) nor does it allow wildcard DV Adobe-managed certificates. Therefore each subdomain requires - Configuration via the Domain - Domain verification via additional TXT record - Set up a dedicated DV manager certificate   Although one could use a custom wildcard certificate right now, that needs to be OV/EV (too expensive for DEV/STAGE purposes) and also the management per subdomain still needs to be done manually. Improved/Expected Behavior: Allow wildcard domains so that the setup is only necessary once, instead of per sub domain. This requires:- Allow configuration of wildcard domains in Domain management - Allow Adobe managed DV certificates for wildcards (supported by Let's Encrypt with every ACMEv2 compatible client) - Adjust UI to allow mapping the wildcard certificates to the wildcard domain Environment Details (AEM version/service pack, any other specifics if applicable): n/a Customer-name/Organization name:   Screenshot (if applicable):   Code package (if applicable):  

bjoern__koth
bjoern__kothNew Participant

Web SDK - Simplify and fix Cookie Consent HandlingNew

Description - the current Web SDK "set-consent" behaves a little unexpected in different situations, leading to unwanted results, whereas a the legacy Visitor ID service behaved differently.   Examples:   A) A new visitor denies cookies. With the Visitor ID service, you would've just denied the consent categories, mapped to the Adobe tools without having any whatsoever cookie written. With the Web SDK however, if you send a general "opt out" through the "set-consent" action, two things happen "kndctr" cookies are set (!) if the company has a RT-CDP license, a pseudonymous profile is created (correct me if am wrong!) with the consent preferences attached to it   In my opinion, none of the two above make sense, and cookies written lead to potential legal problems.   Now, I am a seasoned Launch developer and have a workaround that involves local storage and some other constructs to make sure the "set-consent" rule only triggers (and writes cookies and creates a profile), when it is needed.   I am wondering what happened to the super simple approach with the old Adobe optIn API.   Why is this feature important to you - ease of use, legal compliance and cost control. If I don't consent, why does the Edge network return cookies. And when I am a new visitor without consent, why create a profile?   How would you like the feature to work - Web SDK should send a set-consent call if a user previously consented and changed his settings e.g., now opts out. a user gives consent to be tracked ("collect")   Web SDK should NOT send a set-consent call if the user has never consented and rejected all consent categories, resp. the "collect" category   Current Behaviour - opt out with cookies stored on client side and needed workaround in place to disable Adobe tools and functionalities that were automatically handled through the Visitor ID Service in the past.