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.
Workflow route | Description |
---|---|
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 because 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 take all true routes option (also known as an AND-split), 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 route | Description |
---|---|
![]() |
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.
|