Control flow between activities at runtime is determined by transitions.
A transition always connects two activities and is visualized by a blue arrow between activities.
At runtime, after the source activity instance is completed the transition is instantiated and, if available, a transition condition is evaluated (see below). If the condition evaluates to TRUE the subsequent activity instance is instantiated.
Transitions are displayed by an icon showing a small line with labeled ends. In diagrams transitions are rendered as a blue line with an arrow indicating the transition direction.
Splits are modeling constructs for choices or parallel activities.
An AND-split indicates the start of a parallel workflow processing. Each transition is evaluated and followed if the evaluation results to true. An AND-split is marked by a square with a plus sign in the middle.
An XOR-split indicates a decision point where only the first transition is instantiated that condition evaluates to true. The evaluation order corresponds to the order of transitions listed in the XOR split properties. XOR splits are marked by an empty square.
Joins are modeling constructs to merge parallel parts of the flow.
An AND-join waits for all incoming transitions before the join activity instance is instantiated. It is drawn as a square with a plus sign in the middle.
An XOR-join waits and instantiates a new join activity instance on every single incoming transition. It is drawn as an empty square. If multiple incoming transitions are instantiated at runtime the join activity is instantiated multiple times.
The square in the transition, which represents AND-Split, OR-Split, AND-Join or XOR-Join is called gateway. In some cases you do not see the type of the gateway from the diagram alone, for example if a gateway is a split gateway of the preceding or the join gateway of the next activity. Then use the gateways tooltip. Move the mouse over the gateway to display the name of the activity and the type of control flow.
Transition conditions are specified if the successor activity is to be performed under particular circumstances only. If a transition condition is set to true, the transition will always be traversed and the successor activity executed.
In Stardust there are no explicit model elements to specify a process start activity or process completion activity. Instead, the runtime behavior is as follows:
After a process instance is created, the unique activity, which has no incoming transitions, is instantiated. This is called the start activity. The Stardust deployment process guarantees that no process can be deployed which has no unique start activity.
A process instance is completed when all activity instances are completed and no new activity instances can be created. This is called implicit process completion.
See also the next section for more details on triggering a process.