Workflow Processes Can Have Multiple Branches
Using the workflow event dependencies, a workflow process may have multiple branches. There are several reasons why you may want to set up a process to contain multiple branches:
There may be events that can run in parallel. This is useful if the related tasks take time to execute. For example "Read Meter" and "Send Confirmation and Wait for Response". Both can be executed in parallel and event 5 will execute based on the outcome of events 3 and 4. The following is an example of such a workflow process.
In the example above, if event 3 is canceled and event 4 completes, (or if event 4 is canceled and event 3 completes), event 5 will proceed. However, if both event 3 and event 4 are canceled, all remaining events will be canceled.
It should be noted that if either event 3 or 4 fails, ALL events in the process will be canceled, including events in a different branch.
You may have a business process that has some common events and some events that are mutually exclusive. Rather than setting up several processes, you can set up one process that branches based on specific criteria. For example, perhaps you get to a certain point in a process that differs based on whether or not a meter is installed. If there is a meter, you follow one branch and if there is no meter, you follow a different branch.
In the above example, event 2 determines if the workflow process is associated with an existing customer or a new customer.
For a new customer; events 3, 4, 5 and 6 are executed.
For an existing customer, events 7, 8, 9 and 10 are executed.
Event 2 does this by creating an entry in the Context collection indicating which branch should continue. (For example Context Type / Value of BRANCH / A ). Events 3 and 7 should be special events whose purpose is to read the BRANCH context type and determine if its branch should continue or be canceled.
In this example, Event 3's algorithm will continue if the context value for BRANCH is A and Event 7 will only continue if the context value for BRANCH is B.
Note: 
The above diagram and description indicates the use of context records to determine which branch to continue. If your implementation chooses to use characteristics instead, the same logic above may be implemented using characteristics as well.