Build better products with our product team
I like to group all kinds of things by Group. While it appears to be an option with Custom Forms, it's not a true Group ownership. I've been using the Share function to grant Groups access to Custom Forms as applicable, which works at the surface. If a form, though, has no Group access assigned, the "Group" appears to default to some sort of association with the creator. If that creator moves Groups, the form doesn't follow. This makes it difficult to track who and how Custom Forms are managed.
User gets assigned tasks with generic, non-descriptive names. Once they figure out what they are supposed to do, they would like to be able to add a nickname for that task so they can better find and bill to it.
Users would like the ability to Temporarily Hide Tasks/Projects on Timesheet when not actively working on them. The list of tasks/projects on their timesheet is very long and they would like to be able to manage what they see.
If you don't use commit dates and everything is based on planned dates setup by the project manager, as a system administrator you should be able to remove commit dates from the product. When commit dates are removed, no user will see them or set/change them anymore. To be honest, most users don't even notice commit date until it starts messing with their projections. In the innovation lab there have been numerous requests to change commit date behaviour, that either haven't been implemented, or have been marked implemented when the solution doesn't actually resolve the issues users are experiencing.The historical requests to fix commit date include:1. Give system admins an option to remove "Commit Dates" from the system ‚Äì 2100 pointshttps://one.workfront.com/s/idea/0870z000000PSAKAA4/detail2. New Home: Admin ability to customize left side Work List ‚Äì 970 pointshttps://one.workfront.com/s/idea/0870z000000PSgfAAG/detail3. Viewing Planned Completion vs. Commit Dates ‚Äì 510 pointshttps://one.workfront.com/s/idea/0870z000000PSB0AAO/detail4. Commit Dates Approvals follow the same flow as all approvals ‚Äì 180 pointshttps://one.workfront.com/s/idea/0870z000000PSaMAAW/detail5. Ability to reject a proposed new date (commit date) ‚Äì 150 pointshttps://one.workfront.com/s/idea/0870z000000PSZRAA4/detail6. change the view for "Assigned To" view to use planned completion date instead of commit date ‚Äì 100 pointshttps://one.workfront.com/s/idea/0870z000000PSG1AAO/detail7. Home: Make Commit Date Field Editable ‚Äì 90 pointshttps://one.workfront.com/s/idea/0870z000000PSmAAAW/detail8. Provide option in set up area to turn off automatic set commit date ‚Äì 70 pointshttps://one.workfront.com/s/idea/0870z000000PSlQAAW/detail9. Allow clearing / deleting a commit date on a task ‚Äì 60 pointshttps://one.workfront.com/s/idea/0870z000000PSShAAO/detail10. Progress Status on Commit Date Later than Planned Completion Date ‚Äì 70 pointshttps://one.workfront.com/s/idea/0870z000000PSlKAAW/detail11. Allow change of commit date by PM after team member clicks "Work on it" ‚Äì 60 pointshttps://one.workfront.com/s/idea/0870z000000PSpdAAG/detail12. Commit Date User Control ‚Äì 40 pointshttps://one.workfront.com/s/idea/0870z000000PScwAAG/detail13. Ability to batch update commit dates ‚Äì 30 pointshttps://one.workfront.com/s/idea/0870z000000XiFvAAK/detail14. Users with Manage it Access to Projects/Accepting Commit Dates ‚Äì 20 pointshttps://one.workfront.com/s/idea/0874X000000sYLlQAM/detailSo here is one idea that address all of the above, without impacting any current instances that are actively using commit dates.1. Under ‚ÄòSettings’, ‚ÄòProject Preferences’ there is a default setting for how projects handle commit dates. Sys admins can set this to:¬∑ Set to planned when editedIf ‚ÄòTrue’ or enabled, (default) Workfront continues to function as it currently doesIf ‚ÄòFalse’ or disabled, changing the status, percentage complete, actual start date etc does NOT populate a commit date ‚Äì the field continues to be blank¬∑ Calculate progress status onCommit Date (default) Workfront continues to function as it currently doesProjected Completion Date Workfront ignores commit date unless accepted by someone with manage rights to the project (which would update the planned date and thus the calculations anyway)¬∑ Commit date editable byIf set to ‚Äòassignees’ (default) Workfront continues to function as it currently doesIf set to ‚Äòassignees and project owner’ all commit dates are editable by the current project owner or the assignee(s)If set to ‚Äòassignees and project managers’ commit dates can be edited by the assignee OR anyone with manage rights to the project¬∑ Commit date changes approved byIf set to ‚ÄòProject Owner’ (default) all commit date approvals go to the project owner ‚Äì current functionalityIf set to ‚ÄòProject Managers’ commit date approvals can be accepted or rejected by anyone with manage rights to the project2. Under ‚ÄòProject Details’, have the same fields as ‚ÄòSettings’, ‚ÄòProject Preferences’Note that this fields can be hidden (deselected) in layout templates, meaning if they are set a particular way in project preferences (and/or templates), sys admins can choose whether project owners can change them or not3. If you have permission to edit the commit date, you have permission to simple delete it. Doing so will have Workfront perform the same calculation for projected completion date that it would if a commit date had never been entered.4. If you have permission to edit the commit date, it is editable anywhere it is displayed ‚Äì home page right pane, any dashboard/report, and view that includes the commit date field, task details pane etc. This includes selecting multiple tasks in a view/report and bulk editing to update or remove it.5. Commit date becomes an option in areas dealing with dates¬∑ A date field option on calendars¬∑ The ‚Äòsort by’ drop-down on the home page¬∑ Left side worklist of the home page (planned for implementation)6. If a commit date is generated that is different to the planned completion date, it shows in the home screen along with task/issue/project status change approvals and proof approvals. The workflow is a single stage with only one approval needed, and either contains just the project owner or all people with manage rights to the project (depending on the setting in project preferences)7. The Project owner and/or users with manage rights to the project can reject a commit date. While the commit date will still be on record, the planned completion date and progress status will NOT be based on the commit date.
Description -From a governance perspective separation of duties between Developing, Approving and Publishing a library is really important to us. Unfortunately, the permissions management in Adobe Launch is not flexible enough to enable us to enforce a separation of duties between developing and approving a library. This is because like many Digital Analytics teams we do not have enough people to have a separate development team with development rights and a separate testing team with approval rights. Instead, users perform both development and testing activities which means they have to hold both the "develop" and "approve" permissions. This means the system will allow the user to approve a library that they have submitted for approval (i.e. they can approve something they have developed, therefore no system enforced separation of duties).Why is this feature important to you -Governance and security is incredibly important to our organisation and many other organisationsHow would you like the feature to work -I would like to be able to prevent people with the "approve" permission from approving libraries they have submitted for approval and only allow them to approve libraries submitted by some one else. A new permission could be created call "approve libraries submitted by others" (or something along those lines!)Current Behaviour -Users can approve libraries submitted by themselves if they hold develop and approve permissions
It would be very useful to know the date that the revision was created when using the compare revisions screen - at the moment you just get the revision number (e.g. revision 3):
Instead of showing the parent object name in NWE Notifications, please show the project name like it did in Classic Notifications, where it showed the project name and task name. Showing the project name in Notifications was more helpful to the user when reviewing their notifications since the parent tasks may use repetitive names.
Show the number of selected tasks. Will help make sure you do not have multiple tasks selected when deleting or moving within large tasks / workbook.
Description -Implement a hashing solution to the Adobe Launch script to avoid security issues such as an attacker tricking a user into downloading content with altered scripts from the compromised serverWhy is this feature important to you -It would ensure secured delivery of the scriptHow would you like the feature to work -Provide an out of the box solution to hash the Launch script for added protectionCurrent Behaviour -No built in tool currently exists in Launch
I am looking for a way to make issues (requests) read only for a group of free users. View permission still allows for posting updates, however, we want to restrict these users from posting updates in the historical requests they have submitted. A true READ ONLY level of permissions would be very helpful
It would be preferable if Workfront could implement the following enhanced features within the timesheets in Workfront:Ability to distribute a set number of logged hours against several projects and/or tasks on timesheet in one entryEffortlessly filter timesheet line items by searching keywords, job codes, etc. Capability to custom freeze columns and rows and view the entire month, not just week, in one screen on timesheets
We would like to see an update in the update feed along with a link in the header of the project and request when requests are converted to projects. I have added screenshot examples below:
Currently, Marketo offers some "Bulk Export" functionality for situations where latency can be higher and many records need to be exported. This is marketed as an alternative to real time calls. However, transitioning from real-time calls to the bulk export feature is not straight forward because the data offered by the real-time call exceeds what is offered in the bulk export call. This specifically affects the data in the "Attributes" property that is offered by both API calls. The real-time call returns more data in that field than the bulk export call. For consistency and to avoid additional API calls when transitioning from real-time to the bulk export API, it should offer the exact same data points in the "Attributes" property as the real-time call.
you should not have to be an admin in order to create or change a workflow. maybe the admin could just give permission to a person to change proofing workflows
Allow Administrators to monitor Email Notifications. Administrators can not tell if Notifications have gone to update a user work was assigned to them. Even if there is just a log for review by the Administrator so we can verify what has gone out.
Allow users to effectively use formatting options like bold, underline and italics within ProofHQ comments. Our business has specific formatting requirements that need to be met for various regulations within creative being reviewed, and without the option to use formatting, the requirements are often missed or misinterpreted between rounds of review.
It would be nice to be able to clear logs and events from one place and/or have the option to not persist between reloads. Why is this feature important to you -It is annoying to have to clear logs and events in different tabs every time I reload.How would you like the feature to work -Under settings you could have a clear all data button and a persist data check box. Current Behaviour -You have to clear logs and events from different tabs.
Training Assets Repository We generate training assets on a regular basis; video recordings of sessions, documents, PDFs, etc... We would like to set up a library within Workfront where users can quickly find what they're looking for across a range of subjects.
It would be great if we could target report emails to users the report applies to rather than it going to an entire group/team/user list.Example - a project report showing projects that are overdue by 10 days or more, sent weekly but only to the owners of those projects and their managers.The recipient section of the recurring email menu would allow you to either select user fields that appear in the report or to add parameters in the same way you build reports.
For agile teams it is difficult to show future capacity/workload and predict when we will need extra resource. Instead of a list for the unallocated resource, it would be useful to show if there is capacity within the team to get these task completed. So if everyone in the team was allocated work to be at max capacity, is there enough resource to cover what needs to be achieved.
The "idea" is to stop counting API users towards the number of licensed users. Assume you have 25 users as baseline and you add a couple of connections, you cut your users in half pretty quickly. In addition, there are separate limits (quota, rate, concurrency) that are shared across all the API users anyway , so it's kind of double-penalizing the usage. Would be nice if this would be changed, so people do not have to go for an API gateway approach (although that comes with different benefits of course).
Markto Outlookアドインのセールスメールについて、受信者がセールスメール開封時にアラートを出しております。 ただし、送信者が送信済みメールを開封しても「セールスメール開封」のアクティビティが付いてしまうため、送信済みメールを確認できるよう自己表示を防ぐ方法、あるいはシステム改良頂ければと思います。 以下設定を組みましたが、結果自己表示は防げませんでした。 自己表示を防ぐ https://experienceleague.adobe.com/docs/marketo/using/product-docs/marketo-sales-connect/email/common-tracking-questions/preventing-self-views.html?lang=ja 送信済みのメールは確認する場合があるため、確認時の自己表示が防げるとアクティビティ精度が増すと思われます。 検討、ご対応の程お願いいたします。
We need the ability to use the Workload Balancer's features on Unassigned Work to placeholder-in allocations in order to judge what Workes might be the best fit.We use a pool system so sometimes we need to see how the allocations might work FIRST to find the best Worker fit.
Currently when viewing issue details, the overview details are automatically open and provide a lot of details that are not necessary for everyday users to view. Custom form details are typically more pertinent so it would be great if we had the ability to rearrange the order of the Issue details to put the Custom form details above the overview, or at the very least automatically collapse the Overview details so they arent expanded by default.
The idea is to separate the permissions between custom forms and custom fields, to allow people to create forms, but not create new fields.We hold the governance of new custom fields at a Global admin Level, which means we have to create all forms as well. This makes sure that our group admins in every agency and market in our global network do not end up creating 100s of duplicate fields (either in language or slightly different naming for the same data etc etc) in our single instance. As this would 1 make a mess of the system and 2 break global reporting. We need to be able to allow our group admins to only be able to create new custom forms, and not create new custom fields.
Already have an account? Login
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
