Why is it important to understand how a filter is set up and what the filter is showing you? Here are some reasons. To understand what the filter does and why the results are showing in the list and to help identify why something isn’t showing up in the results list. You can’t always tell by the name alone. For example, you may think that the Active Tasks filter shows you all the incomplete tasks in a project, but there are some additional filter rules in there that you should know about. This reads as the handoff date is less than midnight tonight. Handoff date is a date calculated by the system to show when a task becomes available for work.
Task, percent complete, less than 100. This is another way of saying that this task is not complete. Using the percent complete avoids a potential problem that results from using statuses to check for task completeness.
Task, status, not equal, complete will filter out any task with a status of complete. However, it will not filter out any statuses that equate with complete. When a system administrator creates custom status names in Workfront, they can equate it or say it’s equal to one of Workfront’s three default statuses. New, in progress, or complete.
For example, some customers create a status called canceled and equate it to complete. The filter rule for task, status, not equal, complete won’t filter out tasks with that canceled status. But, task, percent complete, less than 100 will filter out both the complete and canceled tasks. Task, can start. This field on a task is true if there are no incomplete predecessors and the can start field is true for all the tasks parent tasks. This filter defines an active task as not only an incomplete task, but as a task that can be worked on right now.
Now let’s take a look at the my tasks filter. There is only one filter rule. Assignment users, id equal $, $, user.id. Workfront created this built-in filter using this filter rule rather than task, assign to id equal $, $, user.id. Why? Task, assign to id equal $, $, user.id. It only tells you if you are the task owner, but it will not tell you if you are one of the other people assigned to the task. By default, the first person assigned to a task is the task owner. Their id is recorded in both the assign to id field and the assignment user list. Assignment users, id equal $, $, user.id checks the ids of all the people assigned to a task to see if the id of the logged in user is on the list. This is what you should use unless you’re sure you only want to see tasks where you are the task owner. Finally, let’s look at unassigned tasks in my role. The first filter rule is task, assign to id is blank. Remember that by default, the first person assigned to a task is the task owner. Their id goes in the assign to id field, so the easiest way to see if a task is not assigned to any user is to check this field. Even if there is not a specific user assigned to a task, it can still be assigned to a job role. Task, role id equal $, $, user.role ids reads the job role id of this task is equal to one of the job roles of the logged in user. This is most likely what you would want for this filter, but when you type in $,$ in the name field, you see another option, $, $, user.role id. This is the primary job role of the logged in user. Choose this if you want to only see tasks assigned to the logged in user’s primary job role. The $, $, user.role ids list contains the primary job role as well as other job roles assigned to a user, though it’s not necessary to include both wildcards.
Task is complete, equal, false. This is another way to say the task is not complete. It is the same as task percent complete less than 100. Meaning that it will also take into account any status that equates with complete. By knowing how a filter is built, you can decide if it’s meeting your needs. If you want to change a built-in filter, simply make some edits and save it as your own custom filter.
