Hi,   To achieve this, you would need to add a calculated field to your projects that calculates the number of days between the request entry date and the planned Completion Date of the project (assuming that plannedCompletionDate is the same as the target live date). The calculation would look some...

Hi,   This can be achieved with the following text mode filter:   actualCompletionDate=FIELD:plannedCompletionDate actualCompletionDate_Mod=gt   Best Regards, Rich.    

Hi,   I can see that there are four statuses used in this formatting rule. Should all of them appear in orange when pending approval? If yes, you will need to append ":A" to all of the status codes, so the line of code would look like this:     styledef.case.0.comparison.righttext=HFA:A WJL:A EQB:A ...

Hi,   In the requests area of Workfront, under the "submitted" tab, there is a column called "Converted to" which will show the resolving object (be it a task or a project), which will be the item that the request was converted into.   On the actual request itself, in the details tab, there is a fie...

Hi,   You'll need a little text mode to achieve this, but it can be done by following these steps:   (1) Go into the report editor, select the status column, then advanced settings and add your formatting rules for the "Compliance request Check" status.   (2) Once your formatting is added, switch to...

Hi Mesh,   I don't believe there is a maximum amount of sub-tasks that a parent task can have. However, there is a limit to the total number of tasks or issues that can be on a project. I believe that the limits are 5,000 tasks per project, or 10,000 issues per project.   You can read more on this h...

Hi,   You would just need to add an editable field to your report view. This could be the project description field (if you use that for comments), or a free text custom field that is attached to your projects in the system via a custom form.   Best Regards, Rich.

The reason for avoiding two fields was that it makes reporting difficult. . . . This problem goes away if you have a third calculated field that references them both because you now only need to include one field in your report, if that makes sense.    

Hi,   The way I have overcome this in the past is to create two separate fields (one required, one not) driven by display logic, exactly as you have outlined. And then create a third calculated field that returns the values entered into the first two fields i.e., CONCAT({DE:Field 1},{DE:Field 2}).  ...

Hi,   In addition to Joaquin's excellent advice, you may also need to check that the access level allows people to edit users in their group. See below.     Best Regards, Rich.