Episode IV: Workflow Wrap-Up
In case you haven’t read them yet, here are Episode I, Episode II and Episode III for your enjoyment. In this week’s installment, we will be discussing the utility and power of Parallel Workflow Threads within Teaming, something that we’re sure you’ve just been dying to learn about.
A Parallel Workflow Thread is simply a way of allowing your Workflow to complete multiple functions simultaneously. For example, if you want to submit a Pricing Proposal for review, it probably needs to get the stamp of approval from each member of a Pricing Committee. Instead of sending your proposal to the committee members one at a time, Parallel Workflow Threads allow you to send the proposal to all members of the committee at once, significantly speeding up the review process.
We’ll walk you through the process one step at a time. The graphic below shows an example of a Workflow that uses a Parallel Workflow Thread to send a form to three different review states simultaneously. The example that we have used up to now doesn’t really need parallel threads, however, this was way too important to pass up. This is the workflow that we’ll be teaching you how to make. We’ll show you how to do it once, and then you can replicate the process in order to produce as many simultaneous procedures as you want.
Yes, this might seem complicated. But don’t worry, its easier than it looks. You’re ready!
So, how is this done? Well, if you’ve been paying attention through our series of articles, you already know how to do most of what is required. You already know how to build states, initiate transitions, and all kinds of other neat things . But let’s get into the good stuff. How do you make a Parallel Workflow Thread for yourself?
Well, first you need to build the framework. How many review processes are there? What are the reviewers’ choices? When you have built all the states you think you need, then you can really get started. Let’s use the example we have provided above. First, we need to set up two parallel threads. The green dotted arrows represent the initiation of these parallel Threads, and the red dotted lines represent the end of these threads. In order to create these threads, select Workflow Process > Add > Parallel Workflow Thread. This pulls up the following screen:
You can see that Review Two Start is selected as the first state in the thread and Review 2 Complete is the final state. We repeated this process with the Third Review.
If you have 3 paths, you only need 2 parallel threads, because the first path is the original workflow and it needs no threads or other actions to get it to work.
After you establish the start state and the end state for a Parallel Workflow Thread, you set up the other states and transitions in between by following the same instruction given in last weeks episode.
Now we come to a crucial step. How do we get the workflow to recognize that the reviews occurring in the Parallel Threads have finished, so the workflow can proceed? You need to change the first review path. Select the final state of your first review process, which is now Review One Complete. Select Transitions > Add > Wait for Parallel Thread(s) to End. You will see the following;
Notice that you are able to select more than one Parallel Thread. We have selected both threads, and when they are complete we’ll send the total package on to the Review Stage Complete state. This sends the whole workflow, including the review results from all three reviews, for analysis in order to complete the process.
The fact that the workflow remembers decisions made in parallel workflow threads is probably the most powerful aspect of the Thread feature. We set up the workflow so that when a document or proposal is reviewed by any of the three reviewers and enters the Accepted, Modifications Required, or Rejected states, the workflow records a workflow variable. This is done by selecting a state, such as Reviewer One Approves, then selecting Add > On Entry > Workflow Variable. You can assign any name and any value to a variable which will then be carried throughout the remainder of the workflow, unless you opt to have it changed to a different value at a future state.
All the variables from all the states of all the threads are compiled when the Parallel Workflow Threads end, and you can use them to determine future transitions, as we have done in this example. You can see that we have created states called RejectVariableCheck and ModVariableCheck. These states use Transition on Variable to check for workflow variables associated with rejection or modification. If any such variables are found (that is, if any reviewer sent the item to Reject or Modify and the workflow therefore assigned an accompanying variable), the workflow transitions the item to the Rejected state or back to the Originator for modifications.
If no variables are found, then Transition on Time Elapsed comes into play. Both RejectVariableCheck and ModVariableCheck states also have a time-elapsed transition, which waits one minute for the variable check to complete itself. If no variables are found to reject the document, it is sent to a Modification check one minute later. If no variables associated with modifications are found, the item is transitioned one minute later to Document Approved. This combination of Transition on Variable and Transition after Time Elapsed acts as a type of IF / ELSE logic statement, and results in, yep, a really cool workflow…
That’s all for now. See you next time!