Product ideas | Community
Skip to main content

10000 Ideas

ncdd23New Participant

Autosave/Drafts for Requests being Created within a ProjectNew

Description - After a thorough implementation, we decided to use the Request Queues built directly in the projects. The functionality is great. We have a project template set up with Queue Topics, Groups, Forms etc. The issue is that when creating requests directly in a project there is no Autosave or Drafting functionality that we know of. Our users are becoming increasingly agitated by having complex requests easily deleted at the unfortunate click out of the request window or accidental refresh of the page.   Why is this feature SO VERY important to you - Our current solution is to submit requests without auto-routing to a traffic team so the work can be saved. Leading to needing to save as you go, something that is antiquated in this day and age, especially knowing that autosave exists in many other places in Workfront, including the Global Request Queues area.   How would you like the feature to work - simply autosave as you go with a Drafts section built into the Request area of the Project. Or a new section called Request Drafts. Draft autosaves until the Submit Request button is clicked.    Current Behaviour - User begins a request, fills out info and has to Submit the Request in order to save it and continue working on the request, and they must click save as they progress. If users haven't submitted the request yet or haven't recently saved, it is very common for users to accidentally click out of the window, closing the request and clearing all the info. Leading them to have to painstakingly recreate the request they could have spent many hours on.   Please prioritize this, WF.

BrentHat
BrentHatNew Participant

Add Default Planned Hours to Queue Details of projectsNew

Description - A user should be able to set the the default number of hours that a request will take IN ADDITION to the Default Duration that can be set. Currently, if hours are used to describe the Default Duration, the Request will have a start and end date/time based on those hours. However, Requests should be defined by both the Planned Hours set (e.g. 2-3 hours of working time) as well as the total Duration of the Request (e.g. 3 days). If a user chooses 3 days as the Default Duration, the system assumes that the assignee will allocate 24 hours of working time to complete the Request. If a user chooses 2 hours as the Default Duration, the system assumes that the assignee will be done with the Request in 2 hours time. The system should account for both forms of timing.   Why is this feature important to you - As Requests are made, the incorrect Planned Hours based on 3 days of duration are assigned to the working team member. These hours, while not accurate, often spike their capacity for the 3 days they are working on the Request. It requires additional management of the Request to update the Planned Hours and this can often be overlooked.  How would you like the feature to work - An additional field called Default Planned Hours would pre-set the expected hours needed to complete the Request within the timeframe set by the Default Duration. Alternatively, if there was an option to convert a Request to a Task using a Task Template (currently, only Project Templates exist), a user could select a template that has both Planned Hours and Duration preset. 

HachidoriNew Participant

Project Finance Recalculation Tracking in project System Updates and Audit LogsNew

Description: Finance Recalculations on a project do not trigger a system update or appear in the Updates tab, Audit Logs, or the Adobe Admin Console Audit Log. Per a recent Workfront Support request, I was informed that this action is considered a background process and is not currently tracked in the standard system or audit logs, and there’s no built-in setting to enable logging. Why is this feature important to you -Tracking of hours and actual cost is integral within Workfront for reporting, and is often a cross-departmental mandatory required reporting functionality, sometimes in terms of governance. It should considered as best practice, when finances are recalculated within a project, that there is a system automated date/timestamp and audit log tracking created for this.   How would you like the feature to work -Preferably there would be an automated update of a successful (or unsuccessful) recalculation attempt, which should show which object unique ID the attempt was made for in Workfront System Audit Log and the Adobe Admin Console Audit Log. Further, a System Update should be made within the project Updates menu itself, the same way it would be when a project changes status, etc.  Current Behavior -As stated previously, this very important best-practice feature, I'm told by Workfront Support, is not available at all. The only thing I've noticed upon any sandbox testing of Finance Recalculation on projects is that there is a brief pop-up, that is too fast to read and easy to miss on larger projects (because it can take a very long time staring at a screen for larger projects to Finance Recalculate). 

TamBou
TamBouNew Participant

Bulk Project Comments/UpdatesDelivered

Description - latest change to Project Edit screen removed the last vestige of posting comments by removing the ability to post comments to multiple Projects at once when bulk editing selected Projects. Why is this feature important to you - there is no longer a simple way to put information/comments/updates on multiple relevant jobs creating multi-step process X each applicable project (could be 3, 10, 50, more).  How would you like the feature to work - options (may be others) 1) at minimum, return to the way it very recently was where if you were bulk editing a project one could select the Comment box in the left pane to post a comment to multiple projects at once (cannot do this with single Project Edit for some time);  2) allowing us to Open Summary on Projects in bulk and add a comment;  3) at the very minimum provide Project-level Open Summary panel that includes Updates section as in other parts of the system -- this one doesn't remove the repetition but does reduce it as well as offering easier ways to interact with the Project level data points.Current Behavior - must locate project, click into project, click on Updates 'tab', enter comment, post (with or without additional step of tagging others) then repeat for each relevant project (could be 3, 10, 2, 50, more).  This is a lot of time, steps, repetitive clicks (think ergo) and personal opinion -- boredom and frustration.

LaurenWoodNew Participant

Enhanced “System” Audit Logs in WorkfrontNew

Description -Currently, Workfront's Audit Logs primarily track actions performed by individual users. While recent enhancements (specifically the "Other enhancements during the Second Quarter 2025 release timeframe" regarding Represent Adobe Admin Console user changes as "System" in the Workfront update feed) have introduced "System" activity updates in user update feeds, and these actions captured in the comprehensive System “Audit Log,” however, it’s no longer possible to filter for these log types and action performed by “System” listed under the User Name column.Why is this feature important to you -This highlights a critical visibility gap regarding automated or system-driven changes within Workfront. For example, changes originating from integrations, API calls, automated workflows, or even internal Workfront system updates are not readily auditable through the Setup > System > “Audit Log” page.Improved Transparency and Accountability: Gain a comprehensive understanding of all system-driven changes within Workfront.Enhanced Troubleshooting and Issue Resolution: Quickly identify the source of unexpected changes or errors.Strengthened Security and Compliance: Maintain a detailed record of all system activity for audit and compliance purposes.Increased Integration Visibility: Track changes made by integrations and API calls for better management and troubleshooting.How would you like the feature to work -We propose the creation of a dedicated, filterable "System" Audit Log within Workfront, mirroring the functionality of the existing user-based Audit Log. This log would:Capture all system-initiated actions: This includes changes made by integrations, API calls, automated workflows, internal Workfront system updates, and actions attributed to the "System" user as seen in the user update feeds (e.g., Adobe Admin Console user changes).Provide detailed information: Similar to the user Audit Log, this log should include timestamps, action types, affected objects (projects, tasks, users, etc.), and relevant details of the changes made.Offer robust filtering and search capabilities: Users should be able to easily filter and search the log based on various criteria, such as date range, action type, affected object, and integration/system source.Maintain a consistent format: The log should adhere to a clear and standardized format, making it easy to understand and analyze.Respect existing access controls: Access to the System Audit Log should be governed by appropriate permissions, ensuring data security and compliance.Current Behaviour -The recent change to represent Adobe Admin Console user changes as "System" in the Workfront update feed highlights the need for a dedicated “System” Audit Log. While this change is a positive step, it underscores the lack of a centralized location to track all Workfront system-initiated actions.We’ve confirmed with support that, “The reason, we are unable to search for “System” it's only a text string, and it's not a user. This will need to be a feature request, since the audit logs, are designed to only search for Workfront user objects.” and that it’s not currently possible to access this information via the API.Call to Action -Please vote for this idea to enhance Workfront's audit capabilities and provide greater transparency into system-driven changes. This will empower administrators and users to better manage and troubleshoot their Workfront environment.