This article contains guidelines on how to analyze your processes and convert them so they can be implemented into your Issuetrak system. The actual steps to add Tasks and Task Groups to Issuetrak are not covered here. See our About Tasks article for more information about task management.
It’s best to be familiar with several terms going forward:
|Task||An Issuetrak term defining 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||An Issuetrak term consisting of 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||Within Issuetrak, it is a pre-filled issue template. It allows for individual tasks or task groups to be pre-populated on specific templates for ease of use.|
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.
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 it’s entered into Issuetrak.
Example 1: A simple list of items that need to be done to add a new customer.
To create this process within Issuetrak, the first step is to create a single Task Group that contains these individual tasks. That is also where you can determine who is assigned each individual task within that process. 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 done in order. 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. It’s possible that the different steps may need to be completed by different teams or individuals.
Here’s what the process looks like as a Task Group on an issue:
By documenting your steps ahead of time, you can better understand how the process is represented in Issuetrak. It may help to add more columns on the spreadsheet to help decide which users or groups will be assigned each task and the exact order they need to occur in.
Because workflows tend to be more complicated than a simple process, it’s highly recommended to document all the steps, giving you a better visual before beginning to create the workflow within Issuetrak. Unlike a simple process, 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 are triggered based on the response to an earlier decision point.
This is the documented workflow, complete with decision-based branching:
Looking at this same process mapped in Excel allows for the identification of decision points and helps with designing the Issuetrak Task Groups.
Identifying Decision Points
A decision point occurs anywhere a question is asked. The response to this question determines what steps happen next. These are set within Issuetrak by using Yes/No/NA task types. These tasks trigger other Task Groups to populate into the issue and continue the workflow.
The second decision point only applies if the first decision point gets a “Yes” response. So if the damage is over $500, then approval must be given before the repairs are done. The approval task is your second decision point. If the approval is not granted, the entire process stops, and nothing further occurs.
The tasks that continue on because of the decision points determine what Task Groups will be set up within Issuetrak.
Identifying Task Groups
There are two things that could possibly happen at our first decision point. If the answer is “Yes”, then another task and the second decision point need to be added to the process. So an Issuetrak Task Group is created containing those two items. It will be triggered by the answer of “Yes” to the Task question: “Is Damage Over $500”. Since the “No” answer requires a different task, a second Task Group is created that includes only the “Make Repairs” task.
The second decision point also uses the “Make Repairs” Task Group. If the Task of “Purchasing Approves” is “Yes”, then it needs to call the “Make Repairs” Task Group. If the answer is “No”, then the process ends with no activity.
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 with the following tasks:
|Group Name||Task||Response||Call Group|
|Operations – Plumbing Leak|
|Survey Damage and Report||Complete|
|Is Damage over $500?||Yes||Operations – Plumbing Leak > $500|
|No||Operations – Make Repairs|
|N/A||Operations – Plumbing Leak > $500|
|Operations – Plumbing Leak > $500|
|Submit purchasing Form P8||Complete|
|Purchasing approves?||Yes||Operations – Make Repairs|
|N/A||Operations – Make Repairs|
|Operations – Make Repairs|
|Make Repairs||Complete||Close Issue|
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 of “Operations – Plumbing Leak” to be added to an issue.
Pre-defined vs. Free-form tasks
There are two options 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 you 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.
- 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.
The values for these two values 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/N/A tasks
There are two types of tasks. “Complete” tasks are simply to be marked as completed once the item in question is finished. A “Yes/No/NA” task type allows for the branching workflow options. These are especially useful in approval situations or anywhere you have a decision point. Most users find it easier to phrase “Yes/No/NA” tasks in the form of a question.
Task Groups and Issue Templates
Issue Templates are pre-filled issue templates. They can be used to launch the processes and workflows. It’s recommended to create all the processes and workflows in the Task Group area, then only put the initial group on the Issue Template itself. This allows you to reuse a Task Group on any issue, including another Issue Template or an existing issue, giving you greater control of your processes.
Naming Task Groups
When creating and setting triggers to call multiple Task Groups, it’s easy to get confused when looking at the list of available Task Groups. It’s important to consider a naming convention to help keep your Task Groups organized. 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, keeping everything together on the list. See the example below:
You can see that all of these task groups are part of the same process because they all start with “HD - User Access Change”.
Some processes require that tasks are completed in a specific order. The dependency order of a task allows you to control the order that the task is completed. For example,
|Do Step 1||1|
|Do Step 2||2|
|Do Step 3||2|
|Do Step 4||3|
|Do Step 5||No Dependency|
In the table above Step 1 must be completed before you can do step 2. Step 4 Cannot be completed before steps 1,2, and 3, are completed. That is because a dependency order is controlling when the task can be completed. Step 5 does not have a dependency order set so it can be done at any time.
The task that needs to be done first needs to have the lowest dependency order (usually 1). Once that task is completed the task with the next highest dependency order (usually 2) becomes available. After that task is completed, then the task with the next highest dependency order (usually 3) becomes available, and so on. You can also set many tasks to have the same dependency order so that they become available at the same time. For example, all tasks with a dependency order of 1 must be completed before you can move on to tasks with an order of 2. If a dependency order is not set, then a task is available the moment it’s included on the issue.
End Task Groups at Decision Points
When putting your tasks into Task Groups, you always want to use one of your decision points as the last task. This allows the tasks to be added to the issue only when needed, providing a cleaner, more dynamic feel to the issue.
Use Issue Templates to Launch Processes/Workflows
By using Issue Templates to initiate the first part of any process or workflow, it ensures that the beginning portion of the process is uniform. Very often, that Issue Template may only have one question or a small process included, but it prevents having to try to add a process to an issue mid-stream.
Putting It All Together - an Example Process
This example does not follow best practices. All the tasks are visible, whether or not 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 makes the initial list short and well organized. It begins with only a single question, providing less confusion to the end-users. In this case, it only populates the tasks when necessary. After the decision points have been answered.
If you answer “Yes” to that 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 any questions or would like the assistance of our product experts, please do not hesitate to contact us with any questions.