Best Practices - Working with Task and Processes

This article contains guidelines on how to analyze your processes and convert them so they can be implemented into your Issuetrak site. The actual steps to add Tasks and Task Groups to Issuetrak are not covered here, but our About Tasks article contains more information about task management.

It’s best to be familiar with several terms going forward:

Term Definition
Task A single item that needs to be completed. Processes and workflows normally consist of multiple tasks.
Process A list of related tasks on an issue that needs to be completed.
Workflow In the context of this subject, a complicated process that includes decision points that determine the next steps in the process.  Not to be confused with Issuetrak's Workflows feature.
Task Group A series of tasks that define either the entire process or a portion of the process that is triggered by a decision point. Workflows may call different Task Groups, depending on the answer at any given decision point.
Issue Template A feature that allows fields and / or tasks to be pre-populated on submission.

Now that we’ve looked at a couple of the terms that we’ll be working with, let’s move on. We’ll start with simple processes.


Simple Processes

It’s best to understand the process that needs to be added to Issuetrak. Some examples of processes include purchase approvals, access approvals, creation of customer records, or hardware replacement requests. Your processes may be short, with only two or three items, or you may need something much longer. Either way, you will want to determine all the steps involved in each process before creating it within Issuetrak.

If the process is long or complicated it may be helpful to write it down. Documenting the process ensures that no steps are missed when entered into Issuetrak. Click here to download our Task Group Planning Spreadsheet, which contains examples and blank templates that you can use to plan your own task groups before inputting them into your site.

Example 1: A simple list of steps that need to be completed when adding a new customer

Use the Task Group Planning Spreadsheet to map out the task group:

In the Issuetrak site, create the Task Group that contains the individual tasks. This step also offers the option to assign tasks within that task group to individuals or groups as needed. Tasks can also be assigned to the issue assignee (--AssignedTo--) or the issue submitter (--Submitter--). Here’s what the Task Group looks like once created in Issuetrak:

When that group is added to an issue, it looks like this:

Example 2: Hardware replacement request

With this process, each step needs to be completed in order, which is indicated by the Dependency order (Column C) in the screenshot below. A quote on the hardware must be acquired before the department manager is notified. Once the purchase is made, then the hardware can be installed. The different steps may need to be completed by different teams or individuals, which is indicated by the Assigned To (Column D) in the screenshot below:

Here’s what the process looks like as a Task Group on an issue:

By documenting the steps ahead of time, you can better understand how the process is represented in Issuetrak.


Branching Workflows

Because workflows tend to be more complicated than a simple process, it’s recommended to document all steps before initiating them in Issuetrak for better clarity. Unlike a simple process, a branching workflow contains conditional tasks that allow for different actions to occur based on the response, such as changing the direction of the existing process or inserting a new set of steps. This is handled by creating multiple Task Groups within Issuetrak that can be triggered based on the response to an earlier decision point.

Example: A plumbing leak. Once the water leak is repaired, the water damage needs to be surveyed and reported. If the damage exceeds $5000, there’s an approval process to be followed before water damage repairs can be made. If the damage is less than $5000, then the apporval workflow is not necessary, and the water damage be repaired without approval.

This is the documented workflow, complete with decision-based branching:

Looking at this same process mapped out in the Task Group Planning Spreadsheet allows for the identification of decision points and helps with designing the Task Groups.


Identifying Decision Points

A decision point can occur anywhere a question is asked. The response to this question determines what steps happen next. These are configured in Issuetrak by using Yes/No/NA type tasks. These tasks can trigger other Task Groups to populate into the issue and continue the workflow.

In our example, the first two steps are simple to process items. The next task asks the question “Will water damage repair cost more than $5000?”. This is the first decision point. If so, the required form must be submitted and approved before repairs can be made. If not, the repairs can be made without approval.

The second decision point only appears if the first decision point gets a “Yes” response. So, if the water damage is over $5000, then approval must be given before the repairs are done. The approval task titled "Purchasing approves?" is the second decision point. If the approval is not granted, then the second task group is added again so that the required P8 form can be corrected and resubmitted.

Notice that the decision points guide the establishment of Task Groups within Issuetrak by delineating the tasks that persist in the workflow.


Identifying Task Groups

At the first decision point, two possible outcomes exist. If the answer is “Yes”, then more tasks and a second decision point need to be added to the process. So, an Issuetrak Task Group should be created containing those two items which will be triggered by the answer of “Yes” to the Task question: “Will water damage repair cost more than $5000?”. Conversely, as the "No" response necessitates a different task, a separate Task Group should be created containing solely the "Water damage repaired?" task.

The second decision point also involves the "Facilities - Plumbing Leak 03 Repair Water Damage" Task Group. If the "Purchasing approves?" task is affirmed, the "Facilities - Plumbing Leak 03 Repair Water Damage" Task Group is activated. Conversely, if the response is negative, then the second task group is added again so that the required P8 form can be corrected and resubmitted.

Once the Task Groups are identified and the triggers established, the next step is to build out the workflow in Issuetrak. You will have three Task Groups, each with their own individual tasks:

Planning out the process ahead of time allows it to be easily entered into Issuetrak. Once created, starting the workflow only requires the first Task Group “Facilities - Plumbing Leak 01” to be added to an issue since the last task in that group will, depending on the chosen response, automatically add the other appropriate task group when completed.


Best Practices

Pre-defined vs. Free-form tasks

Two methods are available when creating Tasks. Issuetrak comes with a pre-populated list of Tasks that can be customized. However, when creating tasks, you can either use that predefined list or create a free-form task on an ad-hoc basis.

  • Pre-defined tasks are easier to add to Task Groups if you need to use a specific task repetitively or want consistency in spelling or naming conventions. However, these must be entered into the Task section ahead of time before they can be used to build out processes and workflows. Once created in the Tasks section, they can be added to a Task Group by editing the Task Group, clicking the New Task button, and selecting the desired Task from the Task dropdown menu.
  • Free-form tasks are much more flexible, allowing you to create any task at any time. There are no spelling or grammar checks, so there could be a potential concern about data entry errors. Instead of using the Task dropdown after clicking the New Task button, the desired name for the task should be manually typed into the "Or Enter Task" field.

The names of the Pre-defined and Free-form tasks are stored in different fields within Issuetrak’s backend database. We suggest only using Free-form tasks for simplicity. This allows for quick entry and avoids creating unnecessary dropdown values for items only used once.

Complete vs. YES/NO/NA tasks

Two types of tasks exist:

  • Complete tasks are simply marked as completed once the item in question is finished.

  • Yes/No/NA tasks allow for the branching workflow options. These are especially useful in approval situations or anywhere you have a decision point. They can be used to trigger the addition of more task groups, change substatuses, cancel other existing tasks, and close issues. Most users find it easier to phrase “Yes/No/NA” task title in the form of a question.

Task Notes

When creating a task, if the task title alone doesn't provide sufficient information for the task assignee to understand how to complete it, you can utilize the Note area within the task to include additional instructions. It's important to note that this is distinct from the Labor Note field, which appears within tasks after they have been added to an issue.

Issue Templates

Issue Templates are pre-filled forms that can be used to initiate processes and workflows. It's recommended to input all processes and workflows within the Task Groups area. Then, include only the initial task group on the Issue Template to initiate the process or workflow, ensuring a consistent starting point and also allowing the Task Group to be reused on any issue or Issue Template. The Issue Template may contain just one question or a simple process, alleviating the need to introduce another part of the process partway through an issue.

After editing a Task Group that has previously been added to an Issue Template, that Task Group must be removed from the Issue Template and readded in order for the Task Group changes to be applied to the Issue Template.

Naming Task Groups

When creating multiple Task Groups that will be used within a single workflow, the list of Task Groups can become lengthy and visually overwhelming. Unless a display order is set for the Task Groups, the full list of Task Groups is sorted alphabetically, so it's a good practice to name them in a way where they'll be grouped together in the proper order. You can use a common name or abbreviation for the initial group, then use the same name with dashes and additions for the workflow pieces. See the example below:

Initial Task group name: “HD - User Access Change”
Task group that’s triggered by a yes response: “HD - User Access Change: 01 Data Owner Approval”
The next task group triggered by a no response: “HD - User Access Change: 02 Data Owner Denied”

You can see that these task groups are part of the same process because they all start with “HD - User Access Change”.

Dependency Orders

Some processes require tasks to be completed in a specific order. The dependency order of a task allows you to control the order that the task is completed. For example:

Task  Dependency Order
Step 1 1
Step 2 2
Step 3 2
Step 4 3
Step 5 No Dependency

In the table provided, it's necessary to finish Step 1 before proceeding to Step 2. Step 4 cannot be completed until Steps 1, 2, and 3 are completed, as a dependency order has been set on them. However, Step 5 lacks a dependency order, allowing it to be completed at any point.

Tasks are arranged based on their dependency order, starting with the lowest order, which is normally 1. Once a task with the lowest order has been completed, tasks with the next highest order, usually 2, become accessible. Subsequently, completing tasks with higher dependency orders unlocks tasks with progressively higher orders. Tasks with the same dependency order can be set to become available simultaneously. For instance, all tasks with a dependency order of 1 must be completed before progressing to tasks with an order of 2. If no dependency order is set, a task becomes available for completion as soon as it's added to the issue.

End Task Groups at Decision Points

When putting your tasks into Task Groups, one of the decision points should be used as the last task. This allows the additional tasks to be added to the issue only when needed, providing a cleaner, more dynamic feel to the issue.

Putting It All Together - an Example Process

This example does not follow best practices. All the tasks are visible, whether they can be completed. Notice how the list appears long, clunky, and complicated. This can be especially confusing to end-users.

In the next screenshot, best practices have been applied to the same workflow. It results in a short and well-organized initial list. Starting with only a single question reduces confusion for end-users. In this case, tasks are populated only when necessary, after the decision points have been answered.

If you answer “Yes” to the first question, then another Task Group is called and added to the issue automatically.

If you answer “No”, a different Task Group is added. Either way, the process ends with “Data Owner Approval”. Additional process items are then added by using conditional triggers when necessary.

This is only meant to be a general guideline and a list of some best practices when using Tasks and Task Groups within your Issuetrak system. If you have an especially complicated process that you need entered into your site, consider inquiring about consultation or managed services hours with our Professional Services team.