Branching rules
Branching rules help you model complex business logic. They are simple and neat than using numerous decision nodes. Unlike decisions, they are not limited to a maximum of only two mutually exclusive paths.
-
Use a decision to model an exclusive choice decision pattern where only one of the two alternative paths is required for the process to continue.
-
Use a branching rule to model a multiple choice decision pattern where the flow is split into two or more alternative paths.
A branching rule must include the following:
-
A condition (business rule) for each path (destination node) that must be met before the destination node can become pending or active. The business rule set for destination nodes determines which destination node is activated. Any of the target destination nodes can potentially be activated, if each business rule evaluates to True; two or more outcomes can be valid.
-
A default node to execute at runtime if none of the conditions is met; this stops the process flow from stalling.
Note If you do not specify business rules on the output paths, then all paths are executed normally.
Branching can be either OR (inclusive) or XOR (exclusive):
-
OR branching: Allows one or more, or all of the outgoing paths to be taken. The paths are determined by conditions and if none of the conditions is met, the default path is taken.
-
XOR branching: Allows only one path to be taken, thus restricting the flow. If multiple true paths exist, the first path is taken based on the alphabetical order of the activity name. If no true paths are determined, the default path is taken. If the conditions of more than one path are satisfied, the first found path becomes active, and others are ignored. XOR is applicable for all process maps.