This tutorial explains how to migrate your legacy workflow rules into the powerful Visual Workflow System available in JobTraQ (now known as HighGear) X6 and later. JobTraQ does not convert legacy rules to the visual system when you upgrade to X6, to allow you to clean up and streamline your JobTraQ implementation into a few well-designed and powerful visual workflow processes.

Prior to version X6, JobTraQ provided workflow via the Workflow Rules feature. This feature is still available in X6 as the Legacy Workflow System. Each legacy workflow rule comprises two components: a criteria and an action. When a task or project matches the criteria, the legacy workflow system performs the action. After applying a workflow rule, the legacy workflow system chains to more rules. It tests all of the rules again to see if the task or project should run more rules.

Those three concepts of criteria, actions, and chaining have survived in the new Visual Workflow System. We incorporated criteria into the entry node, the decision node, and the split node. The action component of a rule has become an action node. Finally, we made chaining of rules explicit; now the administrator can specify how tasks and projects flow through the process.

This tutorial provides a best practice approach to perform the conversion from the legacy workflow system to the new visual workflow system. You will need to thoroughly understand your legacy workflow rules and the Visual Workflow System itself in order to achieve success. Before continuing, we recommend that you read the Visual Workflow System documentation.

Planning

• Determine where you will perform the migration. We recommend that you perform the migration in a staging environment (i.e. “dev” or “test”). After you have confirmed the quality and validity of the process, you can use JobTraQ’s Synchronize Configuration feature to deploy it to your production environment.
  However, if you do not have a staging environment, you can migrate your legacy workflow into the visual system in your production environment. If you do this, we recommend that you take some precautions to ensure that the migration does not interrupt your organization’s day-to-day operations.
  • Add a special “Testing” Yes/No field to your JobTraQ software implementation. Make the field editable only by administrators, and add it to a special tab visible only to administrators. Give it a default value of No. Do not use this field in your legacy workflow.
  • Add the Testing field to the criteria of the entry node for each visual process you create. Require the value of Yes in all circumstances.
    Since the visual workflow system takes precedence if the criteria of a process entry node and a legacy rule criteria both match the state of a task or project, this ensures that tasks must have the Testing field set to Yes in order to enter this process. This will cause tasks and projects used for business operations to enter the legacy workflow yet allow testing tasks and projects to enter the visual workflow process.
• Identify and describe the business processes that your legacy rules perform. For example, an organization may have a Product Order process, a Service Request process, and a Quality Assurance process. Each of the processes is implemented by a subset of the workflow rules in that organization’s JobTraQ software implementation, but each set of rules represents a distinct process.
• Draw a diagram indicating the order and dependency relationships of the business processes. The example processes in the previous step would be ordered like this:This diagram shows that other business processes depend on the Quality Assurance process, so the organization should start by converting the legacy rules behind the QA process to the visual workflow system. Then they can proceed to the Product Order and Service Request processes.

Migration

Now that you’ve identified your processes and determined the order in which you should migrate them, follow these steps to migrate each one.

• Determine which legacy workflow rules make up the business process. If you used the Process Category feature to organize your rules into processes, this is already done. However, if your rules are uncategorized or you used process categories differently, then you should organize your rules into process categories that correspond to your actual business processes. As you create the process in the visual workflow system, you can refer to the rules in the corresponding process category.
  
• Find the task/project type or types that begin this business process. Use the legacy rules to determine the Task/Project type or types that begin this process, and add that criteria to the entry node. If there are other criteria from your legacy rules that determine when a task should enter this process, input them now. For example, if you know that only tasks can enter your process, then use the Is Project field to select only values of No. Nevertheless, do not remove the Task/Project Created trigger.
  If you do not have a staging environment, add Testing=Yes filter to the criteria as we discussed earlier.With Testing=Yes filter, tasks and projects will continue to use the legacy workflow unless an administrator explicitly sets the Testing field to Yes to allow a task or project to enter the visual workflow system for testing of the migration.
• Find the rules that decide when tasks and projects should enter this business process. Then create a decision node after the entry node. Since each legacy rule comprises a criteria and an action, create a line for each “entry rule” and copy over the criteria to each line. In our example, the Product Order process category has two entry rules, one for when the order is billable and one for when it isn’t.We created a line on the decision node for each rule, containing the criteria, and we created an action node after each decision node line for the action of the rule.

  

• Convert the next stage of legacy rules. This can be difficult. Look carefully at your list of legacy rules, determine the next stage of the business process, and select the rules that implement that part of the process. Then determine which path in the visual process each rule applies to.To continue our example, we found three rules. Two of the rules come after the first action node and one of them comes after the second action node. For this situation, we created two decision nodes and implemented a decision node line on the appropriate node for each rule. In your migration, if you can determine that a rule does not need to come after one of the paths in the visual process, omit it from that path.However, if you can’t tell which path each rule applies to, create a single decision node and connect all the action nodes to it. Implement a line on the single decision node for each of the rules.You may find that a rule specifies to create some tasks like this:If a rule needs to create tasks, then add “create task” lines on the action node you created for that rule. In the legacy workflow system, JobTraQ would create the project and its two subtasks with a single rule, but in the visual workflow system, we will use multiple action nodes.

  

  We added a new “create task” line for the “Fulfill customer order” project. Then we created another action node with two create task lines to create two subtasks, “Create goods” and “Package and ship.” Now let’s look at the configuration of those lines.

  

  The “Fulfill customer order” line looks like this.

  

  The “Create goods” line looks like this. We set the Parent Project to “Use the trigger project,” which is important. This is what makes it a subtask under the “Fulfill customer order” project we created in the previous action node. When you migrate your created tasks from workflow rules into the visual workflow system, set Parent Project to “Use the trigger project” if you want to create a hierarchy of project and subtasks.

• Repeat the previous step until you have finished converting the process into the visual workflow system. For our example, we ended up with this diagram:
• Remove duplication from the process. Remove all but one of the sites of duplication and connect the lines so that the nodes preceding each duplication point to the single copy of the logic remaining. After converting this process, we see that the process after “Order is billable” is identical to after “Order is approved.”
• Test your business process. Before going live with your visual process, test it. Confirm that you migrated all of the functionality of your legacy workflow rules and that it behaves the way you expect.
• Go live. If you performed the migration in your production environment, remove the Testing field from the entry node criteria. If you migrated to the visual workflow system in a staging environment, go to the Synchronize Configuration page in the System tab, check the box to Export Workflow Processes, export the configuration, and then import it into your production environment.