This feature seems like a must with a tool as flexible and customizable as Workfront.We NEED to be able to discourage (restrict) bad practices through the design of the system.Seconding another user's note: For simplifying the training and again, restricting users from bad practices, we should be ab...

It's for "Closing" time sheets for the week.It doesn't happen to apply for the organization I work for and possibly doesn't for you as well. But an Agency kind of environment might want to have time sheets that are signed off on - and closing it shows that the worker is not going to log any more bil...

Can you elaborate on what the two extra clicks are?Is this for a custom form on a task or a project?There might be a workaround, but also, I think there are some improvements that can be made to the accessibility of custom form information

We are excited about this feature being added, but finding issue converting all out custom fields to use custom name fields due to a limitation with reports.The two issues are:1) Using the API name as the default "display name" in a column. This requires us to add a custom display name for every use...

For context we have a custom field that has a label of "Content Class" but an internal name of "contentClass"Anytime we add that field to a report we will have to manually add a custom display name to get it to display in a user-friendly manner.Additionally, this makes searching for these custom fie...

With the new API-friendly option for custom fields, I have found an issue with the default display of custom fields in reports.Columns headers should be user-friendly by default, not system friendly. Thus, they should use the label by default as that is what the average user is aware of.

You have the parentheses close right where you highlighted up to "Weekly") Remove the ) there as well as after "Biweekly") Your new statement should read: IF({#r ADM | Weekday Login Frequency}<=1.5,"Daily",IF({#r ADM | Weekday Login Frequency}<=3.5,"Multiple Logins per Week",IF({#r ADM | Weekday Log...

If you want to allow non-Workfront users to submit requests via email would this work? 1. Set up a generic user with a license 2. Set up an alias email on that user account for each project request queue that you need to open to the public. 3. Set up rules in your email client that forward email...

Workfront allows you to pass variables into the url of an external page: ? ID = { ! ID } & session = { ! $$SESSION } I'm embedding a custom page (node.js Express server) made with data from the Workfront API and using the SessionID from the url to authenticate the API requests. I have some concern...