Revisiting Tasks by Looping

You can make a process backtrack to pick up the process from a previous step but you must anticipate these likely backtrack points and build them into your overall process.

Processes cannot be reversed, but steps can be configured to lead back to prior steps based on whether or not each new hire record currently meets certain conditions. Using any standard field or user-defined field as a decision point, a task can have a transition to one downstream task if the decision field is "true", and have a transition to a different task if the decision field is currently false. This different or secondary task can eventually have a transition back to the original task, forming a loop. When the information in the new hire's decision field finally is true, then the main downstream task can be successfully assigned, and the process stops looping and moves further along towards the end.

As an example, there is a possibility that the company may not be ready for the new hire to start on their prearranged start date, so a loop can be defined that allows pushing back that start date a few times if needed. As the start date approaches, a form can get assigned to the Manager, asking whether they are ready for next week's start date or not. If yes, the process proceeds to the next downstream tasks as usual. If no, the process follows a transition to a different step, which waits for 7 days and may do other activities. Then a task asks the manager again: Are we ready for the new hire to start next week? If no, then the process follows the same loop back to the waiting step. If yes, then the process exits the loop and proceeds to the next downstream task as usual.

In the previous diagram, the new hire and the manager both fill in a form. Then data from these forms is shown to the required reviewer. If the reviewer can make changes to the data, looping is unnecessary. However, if the reviewer can only view the information and must therefore work with the new hire or manager to make changes, the workflow can anticipate this and include a "loop back".

If the reviewer decides that a change is necessary either from the new hire or the manager, the reviewer will fill in two UDFs created for this purpose. Based on these choices, the transitions cause an “earlier” form to be reassigned to its proper assignee. As soon as that assignee submits that form again, the same outgoing transition is triggered and the reviewer has another chance to review the newly corrected data. In this way the loop is completed and the process appears to “return to a prior step” while still following the normal rules.