Figure 33: Inclusive decision with gateway and without gateway
Each of the activities in the examples above had exactly one incoming and one outgoing sequence flow. Splitting and merging of sequence flows was performed by gateways. However, it is quite often possible to lead several sequence flows directly into an activity, or to lead several sequence flows out of an activity. This enables the gateways to be replaced, leading to a concise representation.
Figure 33 shows two possibilities for modeling an inclusive split: On top, the already known representation with an inclusive gateway; in the presentation below, the preceding activity itself has got various exits. The sequence flows leaving the activity “Select Media for Job Posting” are so-called “conditional sequence flows”. They are marked with small condition diamonds at the beginning, which means that they must be provided with conditions. The completion of an activity activates those sequence flows that have true conditions.
Since several conditions can be true at the same time, several sequence flows can be activated simultaneously. The modeler has to express the condition in such a way, that at least one condition applies. Thus, the logic is exactly the same as in an inclusive gateway.
Figure 33: Inclusive decision with gateway and without gateway
Condition diamonds are placed only at an activity’s exit. If an inclusive gateway is used, the exits are automatically conditional sequence flows, thus making a further marking unnecessary.
An exclusive splitting gateway can be represented in the same way by conditional sequence flows leading out of an activity. Figure 34 shows the same exclusive split with and without a gateway. The difference to an inclusive split is that the conditions must be defined in such a way that always exactly one condition is true.
Figure 34: Exclusive decision with gateway and without gateway
In the second case, however, the modeler is not restricted to using mutually exclusive conditions – other than in the first case with the exclusive gateway. In the upper part of figure 34, a change of the second condition “Up to 500 km” into “Up to 600 km” would be a modeling mistake because both conditions would apply for distances between 500 and 600 kilometers so that the two sequence flows would not be exclusive anymore.
This would be absolutely correct in the second case of figure 34, where the exclusive split would become an inclusive one. In the end, conditional sequence flows after activities always represent the logic of inclusive gateways. Inclusive gateways may also have mutually exclusive conditions, thus creating exclusive splits. In this case, however, the split’s exclusiveness in the model cannot be recognized so clearly, because the conditions have to be analyzed, first. The graphic model would lose in expressiveness; modeling faults would easily be overlooked. This also applies to the modeling with conditional sequence flows, because the exact equivalent to an exclusive gateway does not exist.
When activities are followed by conditional sequence flows, one of the sequence flows can be marked as default flow. It will be chosen automatically if no condition of the other sequence flows applies (cf. figure 35).
If two or more normal sequence flows without condition diamonds are leaving an activity, they will all be activated as soon as the activity has been finished, thus generating a token for each exit. Therefore, it is equivalent to the usage of parallel gateways. Figure 36 shows the same parallel split with and without a gateway.
Figure 36: Parallel split with a gateway and without a gateway
Normal and conditional sequence flows can also leave an activity together. Then, each sequence flow without condition diamond generates a token – the others only if their conditions are true. In this case, however, none of the exits should be marked as default flow, because it would never be selected since there are other exits that always generate a token.
Merging alternative paths can also be modeled without gateways. In the bottom picture of figure 37, the splitting, as well as the merging exclusive gateways, have been replaced. In this case, the alternative sequence flows directly go into the next activity. Each single token that arrives at an activity – via any entry - will directly be processed by this activity. The activity will not wait for any other tokens, and the tokens will not be merged. This behavior is appropriate for merging exclusive sequence flows where only one token can arrive.
Figure 37: Merging exclusive paths with gateway and without gateway
Of course, splits and merges with and without gateways can be combined with each other. It is possible, for example, to have several conditional sequence flows leaving an activity, and to merge them later on with an exclusive gateway (cf. figure 38, top).
It must be taken care that the conditions of the conditional sequence flows are mutually exclusive, so that actually only one token can arrive at the exclusive gateway. In the same way, sequence flows originating from a splitting exclusive gateway can be merged without a gateway (cf. figure 38, bottom).
The joining of non-exclusive paths, however, cannot be modeled without a gateway. The model in figure 39 is not correct. When the activity “Write Job Posting” is finished, it emits two related tokens, one to each of the outgoing sequence flows.
The incoming sequence flows of the activity “Select Applicant”, on the other hand, behave as described above: Each time a token arrives, the activity “Select Applicant” is triggered. Thus, this activity is performed twice: Once for the token from the upper sequence flow, and once for the token from the lower sequence flow.
Figure 38: Combinations of splits and merges with gateway and without gateway
The resulting behavior is shown in figure 40. Here, the models at the top and the bottom represent the same thing: The activity “Select Applicant” is performed twice – when the activity “Publish Job Posting Internally” is finished, and when the parallel activity “Publish Job Posting Externally” is finished. Thus, this model does not correspond to a merging parallel or inclusive gateway. Such a gateway would wait for both related tokens and join them into a single token so that the following activity “Select Applicant” would be performed only once.
In special cases, the behavior according to figure 40 may be desired. In this case, the model at the top may be chosen as a simple representation. Here, each token flows independently to the end event. Other than in the model at the bottom, it would not be possible to rejoin the two related tokens again. Therefore, there will not be many situations for applying this model structure.
At a normal join of parallel paths, the different tokens are rejoined into one token. Regardless whether the parallel paths have been created by a parallel gateway or by multiple exits of an activity, they must be joined by a parallel or an inclusive gateway (cf. figure 41). For easier comprehension, the parallel gateway should be preferred, because it clearly indicates that each gateway entrance must receive a token.
Figure 39: Non-exclusive paths cannot be merged without a gateway
Figure 40: If several non-exclusive paths end in one activity, this activity is carried more than once
Non-exclusive paths can also be created by inclusive splits. These can be modeled not only with splitting inclusive gateways but also with an activity and several outgoing conditional sequence flows if the conditions are not mutually exclusive.
The inclusive paths in figure 42 cannot be merged without a gateway (unless multiple activations of the following activity are desired, as described above). Here again, more than one token can arrive. In this case, only a merging inclusive gateway can be used.
The behavior of multiple sequence flows going into an activity is not symmetrical to that of multiple sequence flows coming out of an activity. Multiple outgoing sequence flows without conditions form parallel paths; several related tokens are emitted (figure 43, left). This corresponds to a parallel gateway. However, multiple incoming sequence flows must be exclusive, i.e. only one token must arrive. This corresponds to an exclusive gateway.
Figure 41: Correct merging of non-exclusive paths
This asymmetry is not intuitive; the model in figure 39 looks rather plausible for anyone who is not a BPMN expert. The different meanings of the split and the merge need to be considered in order to avoid modeling mistakes.
Figure 43: Multiple exits from one activity define parallel paths; multiple incoming flows are used for merging exclusive paths
Since there are two ways of modeling splits and merges, a modeler must decide which style to use: with or without gateways?
It is not possible to model entirely without gateways. On the one hand, non-exclusive paths usually need to be merged by gateways. One the other hand, gateways are often required before or after other gateways (cf. figure 44).
If gateways are omitted as far as possible, more compact and smaller models can be created. For some cases, the modeling of splits with an activity and conditional sequence flows may also be considered as a more natural way of modeling. If a decision is made in the activity, such as in figure 45, it seems obvious to lead the different paths directly out of the activity. If the split is modeled with a gateway, it is optically separated from the deciding activity. In this case, the deciding activity provides a result, which will be evaluated afterward for selecting one or more sequence flows.
Figure 44: When a merge is followed directly by a split of another type, both gateways are required
Figure 45: Different possibilities for modeling decisions
In the case of an automated process, the process engine calls a function. It receives back a value from that function, and then it selects the correct sequence flow. Here, the separation of activity and split is suitable, because the process engine is a controlling unit which executes the process logic independently from the called functions. If no process engine is used, however, the deciding activity often is closely connected with the process control. The activity may directly trigger the following activity, or the decision maker forwards the process documents to different persons, based on the result of his decision.
If the purpose of the preceding activity is not to make a decision but to calculate a price, for example, a gateway is more suitable. The activity provides a result (e.g. a price). The following gateway can then select a sequence flow based on that price. The conditions (e.g. exceeding a certain amount) are entirely independent of the previous activity (cf. figure 46). After a decision activity, on the other hand, the conditions at the outgoing sequence flows usually correspond to the possible results of the decision (e.g. “approval” or “rejection”).
The distinction between deciding activities and other activities is purely based on the modeled content, and it can be discussed whether it is useful. BPMN does not make such a distinction. It is a matter of the modeling style whether to make that distinction and model the splits in different ways or not. If required, it can be specified in modeling conventions.
Figure 46: The activity “Calculate Price” provides a result which is then evaluated at the gateway
Figure 47: Decision and merge in a symmetrical way, both without gateway (top). In the second case, this is not possible since the decision is preceded by another gateway instead of another activity.
Since it is not possible to omit gateways completely, there are often asymmetrical model structures when modeling splits and merges directly at the activities. Especially non-exclusive paths must always be merged with a gateway, as it is shown in figure 41. Sometimes, exclusive splits also must be modeled with a gateway, e.g. when the split directly follows an event or another gateway (cf. figure 47).
The corresponding splits and merges are easier to detect if the same gateway types are used symmetrically. Especially in more complex cases with several combined gateways, the symmetrical use of gateways helps to understand the flow logic (cf. figures 48 and 49).
Figure 48: A more complex example in which gateways have been omitted as far as possible
Figure 49: It is easier to understand the logic of the sequence flow if the gateways are used in a symmetrical way
Moreover, the different gateway types are more expressive. If an exclusive gateway is used, it is clear that in every case exactly one sequence flow will be selected. If the conditions at the sequence flows are not mutually exclusive, this is a clear modeling mistake. It is also a mistake if there are cases in which no condition becomes true.
If an exclusive split is modeled with conditional sequence flows after an activity, it is hard to recognize that always exactly one path is being selected. It can only be detected by analyzing the conditions at each sequence flow. If the modeler made a mistake and created conditions which are not exclusive in every case, this semantic mistake is harder to detect, because there is no violation of the BPMN syntax rules.
The model on the right side of figure 50 obviously contains a mistake: For children between 12 and 14 years, both conditions are true. This is not allowed for an exclusive gateway. In the case shown on the left, this is not forbidden, so this model is formally correct. The modeled content, of course, still does not make sense.
Figure 50: More expressive modeling with a gateway: In the right model, the use of overlapping conditions is a modeling mistake
In the end, every modeler has to decide how to handle the different possibilities for modeling splits and merges. Modeling conventions should be used for achieving a uniform modeling style in a project or an enterprise.
