Product ideas | Community
Skip to main content

Ideas

Filter by idea status

10000+ Ideas

Highlight Description field changes (what was added/what was removed)New

Description - Highlight Description field changes (what was added/what was removed) in updates. Why is this feature important to you - This will save users a lot of time when trying to review changes to the Description field How would you like the feature to work - When the text in the Description field is updated, the System Updates section can:Option 1: Record the new text with the old text (combined as one), striking out anything that was removed highlighting it in red, and highlighting anything that was added in green. If colored highlights are not feasible, simply strike out removed text and use bold for added text.  Option 2: Record the system update in two columns, the left being the original text and the right being the new text. In the New Text Column, it would also be great to strike out anything that was removed highlighting it in red and highlighting anything that was added in green. If colored highlights are not feasible, simply strike out removed text and use bold for added text. A basic version of Option 2 is available in Jira. Current Behaviour—When the Description is changed, the system records the updated text as-is in the System Updates section. For a user to figure out what was changed, they have to read the entire description (sometimes this can be very long), and even then, it is hard to find what was exactly updated. Users are forced to use a third-party text comparison tool to determine what was changed. 

Mylah_DLevel 4

Support more than one (or a separate Workfront) Admin Console per company domainNew

Description: An organization with a single domain should be enabled to separate their products across multiple Administrator Consoles. (Of lower priority, a separate idea is that - once an organization is forced to share products on a single console - there should be a single point of contact at Adobe to help manage shared issues caused by console sharing.) Why is this feature important to you: We are a multinational company with a very distributed organizational structure. The R&D department has little business reason to interact with our Marketing department, for example. The introduction of the console has created a lot of work, the unnecessary need for added coordination, and layers of authorization/access because of the current Console constraint that a domain can only be controlled by one set of primary owners - and those owners are arbitrarily the first group of administrators to have migrated over to the console.  Until the admin console, it was very possible for separate business units to set up SSO for their own products and manage their Adobe products without the need to coordinate. This efficiency goes away once all units migrate to the console. If one group migrates to the console first, they essentially own the admin console. They gain decision-making authority for who can use the company's "claimed" domain. These admins are understandably reluctant to share their highest privilege in the console if it means granting access to sensitive or confidential information in their own applications. Furthermore,  at least make all decisions at the highest level going forward as to who else can be added to the console at the highest-provisioned level. Applications owners whose users later migrate to the console are now required to get authorization from primary owners to either share ownership (e.g. Application A's primary admins must decide whether or not to let Application B admins become global admins within the console) at this primary level, or grant permission for the new application to use the claimed domain to set up SSO for the Adobe product being migrated. In addition to the efficiency loss, Admins of one product lose the ability to completely secure their sensitive information from the admins of other products if those Admins "own" the primary console. Using the same example above, R&D information can be highly secretive. Another group should not have the ability to give themselves access to your R&D information simply because of the current architecture of the Admin Console. Furthermore, to set up or migrate accounts for users, the owners of the Primary console must have the SSO-enabled users first created on the primary console in order for the users to be set up on the secondary console. This creates a lot of work for the primary console owners, as well as duplicative work for the downstream application that wants to set up users with SSO. Because 2 or more business units in a company have different products, the units deal with different Adobe representatives who do not connect nor mutually solve a company's overall issues with the console migration. This causes delays, ambiguity as to the root cause of a problem, misinformation, ambiguity with whose responsibility it is to solve the issue, and the need to communicate repetitively. How would you like the feature to work: Let each business unit have a separate console regardless of whether or not they need to set up SSO for the same domain. Do not force groups with separate contractual relationships with Adobe to have to coordinate and set up a governance model simply because of this technical limitation that dictates 1 Domain/1 Console.  Current Behaviour:  The admins of the first application to migrate over effectively (and arbitrarily) gain global management rights to all applications later on-boarded onto the Admin Console.  Later application owners to on-board must request permission to either become global admins themselves or to use the already-claimed domain for their own SSO implementations.  Any user who is to be set up with SSO in that domain must first be set up at the global level (by the Adobe "global admins") at the company before being added as users to any application where SSO is enabled and this increases the administrative and coordination burden. 

William
Community Advisor
WilliamCommunity Advisor

Provide additional fields on Category and Parameter objectsNew

DescriptionWe have hundreds of Custom Forms and thousands of Parameters, many of which are referenced in dozens of automations across multiple platforms, both in and not in Fusion. The only tool that is built into Workfront to help us document and govern these objects is the Description field (forms) or the Instructions field (parameters). The absence of a full-featured data dictionary within the platform is very limiting in what and how we are able to document.We would like additional fields on these object types so we can spend less time tracking down all the areas throughout our stack that are impacted by things like changing a parameter name, or deleting a custom form, etc.While we do want the ability to attach custom forms to a wider array of object types (especially including Teams, Roles, Reports and Dashboards), I believe this need is better served by the addition of a few extra system fields on these objects. Doing so will allow us to build our data dictionaries directly in Workfront. Why is this feature important to youThe frequency in which we or teams we work with encounter errors due to benign changes on Categories and Parameters is having a strong negative impact on our efficiency, productivity, and the perception of Workfront's quality by our users because "it's always breaking." While a data dictionary can be maintained externally, there's no way to encourage or enforce admins/group admins to use or update it as they interact with these object types, as it's not built in to the form editor. How would you like the feature to workOn both Categories and Parameters (maybe even Parameter Options!), we would like multiple additional system fields made available in the form editor so we can add and reference additional details relevant to each object. Open to suggestions on what these fields should be or how they behave, but anything that allows us to input and edit the various entity relationships of a field or form will be helpful. Current BehaviourWe do our best to document dependencies in the one field we're allowed to do so, but it is limiting to us and also confusing to users. (E.g. when using a custom field's Instructions field to document entity relationships of the parameter, that is shown to users interacting with forms and they have no idea what it means.) We have explored using Fusion to seed a collection of Projects and Tasks as a pseudo data dictionary, which allows us 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. 

TylerKrause
Adobe Champion
TylerKrauseAdobe Champion

Trigger off Journey events via Query Service JobsNew

Description - Presently, Query Service jobs do not write to the DCCS (Data Collection Core Services) which results in these events being ineligible to be qualified for event qualification to kick off a journey. I would like to be able to use a Query Service job to kick off a qualifying event for Why is this feature important to you - This would allow us to kick off journeys from a more flexible point of view. We typically have relied on subscriptions to events from our IT partners that we digest via the HTTP API Source. Unfortunately, development of these events is heavily dev intensive and can often take months. We had a use case for a reminder email for a customers order to send 2 days before their quoted pickup time. We frequently see updated date/time for our order pickups, so we need to use contextual data from other events to qualify the send. We were able to right the logic very eloquently in query servives, but we were not able to actually excecute using it, because of the inability to qualify the event via DCCS, even though it looks good on the profile.How would you like the feature to work - I would love a toggle in the dataset level to indicate whether or not I would like the data to be digested via DCCS. Current Behaviour - Event data that is generated via query service jobs are ineligible for event qualification. We're able to write the data to profile, so there shouldn't be an inflation in usage, but we would be able to better utilize the data that we're digesting from our various partners to drive customer facing results.

amariamorarAdobe Employee

Easy to delete or alter custom formsNew

On a recent Ultimate Success call I mentioned that I was concerned about the ease with which it is possible to delete or alter custom forms.  This came of the back of Case Number 00425051 - Accidental deletion of custom form - undelete request, where I had accidentally deleted one of our teams custom forms.  When custom forms are deleted we are required to contact support to get them undeleted, which seems like a step that could be avoided.  As a result I would like to suggest one of the following:          Confirm deletion pop up         Ability to undelete from the system admin settings menu         Custom forms having a ‘lock’ that requires and extra step to unlock I believe any of the above would have prevented me from deleting the custom form.  In another incident recently a staff member with Admin access altered a custom form with an additional data requirement, which then resulted in all existing copies of that form no longer displaying data until the new data requirement had been met.  This makes sense but it not immediately obvious, it would also be beneficial we had a way of saving custom forms so that experimentation can be done, although maybe its best that I ask changes are first made to the form in the preview environment to check compatibility.  Finally, If a field is deleted from within a custom form it seems all historical data collected by that field is lost, it would be good to have a way of reverting changes etc if needed to avoid data loss.