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 will probably need 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. 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 will be able to replicate the process in order to produce as many simultaneous procedures as you want. Click to Enlarge We hope you've read our other episodes and 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: Click to Enlarge You can see 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 three paths, you only need two parallel threads, since the first path is the original workflow and it needs no Threads or other actions to get it to work. After you have established the start state and the end state for a Parallel Workflow Thread, you set up the states and transitions in between by using exactly the same methods as you learned in the previous episodes. 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 in the first review path. Select the final state of your first review process, which is how Review One Complete. Select Transitions > Add > Wait for Parallel Thread(s) to End. You will see the following; Click to Enlarge   Notice that you are able to select more than one Parallel Thread. We have selected both Threads, and when they are complete we are sending the entry to the state Review Stage Complete. This transitions the entire entry, including the review results from all three reviews, on 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 have set up our 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 then 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 (meaning, if any reviewer sent the item to Reject or Modify and the workflow therefore assigned an accompanying variable), the workflow transitions the entry 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 the 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 on to a Modification check one minute later. If no variables are then found associated with modifications, the item is then 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... Stay tuned as next week we begin to figure out the Form.