To specify how work will progress from one step to the next, you define routes between the steps in a workflow definition. With the exception of the last step on the map, every step has one or more routes leading from it.
Note that the label, or name, that you specify for the route might not display the complete name, depending on the size of your display. You should test how the name displays and adjust the length appropriately.
Route flow | Details |
---|---|
Always true |
Only the most simple workflows proceed in a linear manner from one step to the next. In the illustration (left), each route is always true; there are no conditions. TIP If you define a condition for the only route from a step, if the condition does not evaluate to true when the step completes, the workflow—or the specific branch of the workflow—will stop. |
Route condition |
Most workflow require branching at various points, either as the result of a response made by a participant, or based on the value of one or more fields in the workflow. In the illustration (left), the route from the launch step is always true. The route from the Eval step depends on the value of a response by the participant at the Eval step. (The route condition could also be based on the value of an expression.) Only one of the routes will be taken.
|
Take all true routes |
When there are multiple routes from a step, and more than one of those routes can evaluate to true, there are two options for handling the routing:
When you specify the option to take all true routes (known as an AND-split option), the work splits into multiple child work items. In the illustration at left, the route to Graphics is always true, and either route A or route B can be true, so at runtime there are two separate work items: one for Graphics, and one for either ReviewA or ReviewB. To create a valid map, you must define a collector step as shown at the Edit step that brings the work back into a single path at the end of all the true routes. Note that the processing will wait just before the collector step (Edit) until all of the child processes—in this case, two—reach this stage. |
Special case for AND-split | Details |
---|---|
![]() |
For some applications, it is desirable to specify simultaneous processing (an AND-split), but it might be inconvenient to wait for all the child processes to reach the collector step in order for processing to continue. In the workflow shown at left, the workflow author wants to allow the work to continue in the ProcessA step, the Approve step, and the rest of the workflow without waiting for the Archive step to finish processing. In the illustration at left, Submap1 contains an AND-split at the StartStep to produce two separate work items.
To avoid waiting for the Archive step to complete, the ProcessA step is defined as the collector step. This specifies the work item on the ProcessA path as the parent (which will continue), and releases the child work item (the Archive path) that ends at the TerminateBranch step. NOTE If either the Archive or the TerminateBranch step is defined as the collector step, both the ProcessA work item and the Archive work item will continue after the submap completes—there will be two work items at ReviewDocs and continuing for the rest of the workflow. |
For step-by-step procedures, choose the appropriate topic:
How do I ...? | See: |
---|---|
Define routes between steps | Create a route between steps |
Indicate that a route is "always true" or has a condition | Specify route properties |
Specify possible responses for a step | Specify responses |
Indicate that taking a route is based on a response | Assign a response to a route |
Specify a conditional expression for a route | Specify a routing expression |
Indicate whether work following a step follows one path only or multiple true paths | Specify outgoing routing |
Designate a step as a collector step | Specify incoming routing |
Ensure that the workflow map is valid | Create a valid workflow map |