Exclusive Gateways are the fundamental form of a gateway. They are used to build simple jumping solutions to other elements of the Process. Each Exclusive Gateway can be used to jump back stream to a previous Task (as seen in Type 1, below), to split a flow in to one of several routes that recombine later (as seen in Type 2, below), or to split a flow that allows for termination of the Process earlier than some of the other potential routes (as seen in Type 3, below).
Type 1 - Process Return
This type of Exclusive Gateway is used when returning the flow from a task in the process back upstream to a previous point. In the below example, the Exclusive Gateway is simply being used to verify a successful entry.
It is unlikely that this type of example will be used as it is usually used in the example that follows. However, this method can be used to verify the number entered is within a defined limit.
Below is an example of an extended Exclusive Gate, where the gateway simply jumps back up the flow of the process by more than one task. Its best usage is shown below.
Here a number is entered, and the flow continues. When the flow reaches Task 2 the user sees the number that was entered in Task 1 and is asked if the number is acceptable.
If the answer is unacceptable, then the flow returns to the number entry Task for a retry. This could relate to the value of specific goods, the quality of a test for re-evaluation or a KPI measured at a point which is deemed unacceptable.
The returning branch can contain additional tasks before re-joining the flow further upstream.
Bad Practice of a Simple Return
This next example demonstrates bad practice when using a process return.
In this example the user has incorrectly sent the split to the wrong task (“Task 1” instead of task “Number”) thus the process will become stuck in a loop that cannot be completed and the Process will need to be aborted without conclusion.
Type 2 - Splitting Gates
Splitting using an Exclusive Gateway
This type of Exclusive gate splits the process into one of several possible routes. The below example demonstrates how the user would define an exclusive gate to go about splitting a Process.
The flow into the gate is split into a conditioned route when the path is true based on an expression and a default route when the condition is not met. This ensures that there is always a valid route from the gate.
The Exclusive Gateway is only evaluated when called and any change to the condition after execution will not affect the decision at the point of gate execution.
NB: As in all conditional gates, there should be a default flow so that there is always an exit point.
Closing an Exclusive Gateway
The above example shows the start point of an Exclusive Gate. However, to maintain good practice there should be a closure of this gate and in the diagram below is an example of how this is done.
For an Exclusive Gate there should always be a closure gate for the process. This is not a strict rule, but best practice would be to include this in the Process. This allows the user to identify the elements within the flow that are subject to the route splitting of the gate.
The above Gateway now has effectively two inputs and a default output to the next Task.
Multiple Branches Using an Exclusive Gateway "3 Call"
It is also possible that an Exclusive Gateway can be used to evaluate more than one alternative path. In the diagram below it can be seen that two conditional routes can be split from an Exclusive Gateway.
For the above solution to function each condition exiting from the Gateway must be unique so that only one path is valid at any one time.
In this case the Conditions must always be unique and be of a singular condition for each branch. As in all conditional gates, there should be a default flow so that there is always an exit point.
Multiple branches using an Exclusive Gateway "4 Call"
In this example three conditional routes have been configured from an Exclusive Gate.
In this case the Conditions must always be unique and be of a singular condition for each branch.
For the above solution to function, each condition exiting from the gateway must be unique so that only one path is valid at any one time.
Incorrect use of an Exclusive Gateway to produce an “OR” gate
To overcome the failure in the process above see section, the user may be tempted to create an “OR” by directing two paths to a single Task.
This method will work, however it is deemed a bad practice as the "OR" function should be controlled via an Inclusive Gateway. Please refer to (NEEDS TO BE LINKED TO FUTURE ARTICLE BEFORE PUBLISHING) Inclusive Gateways to understand their usage as these allow for "OR" statements in the condition.
Type 3 – Splitting Gateway with Independent Terminations
These types of Exclusive Gateway split the Process into one of several possible routes with differing process closure points.
Method of Terminating a Branch from an Exclusive Gateway (Best Practice)
It is possible in a Process using an Exclusive Gateway to terminate one of the executable branches. This is only possible because the requirement for an Exclusive Gateway is to only allow one path to be executed.
In the example below, if this path executes Task 5 then it simply completes and the flow ends. If the route passes through Task 1, Task 2, or Task 4, which then jumps to Task 3, then the combining gateway should be used as a best practice approach.
Terminating a branch is a viable approach, however the branch from the Gateway must be unique and the only branch being executed. This uniqueness is mandatory for Exclusive Gates but must be controlled for Inclusive Gateways.
Method of terminating a branch from an Exclusive Gateway – (Not Best Practice)
In the below example, if we were to link Task 5 to the Process conclusion then the Process will still be valid as noted above as only one path will be true on executing the splitting Gateway. However, this avoids the use of a Combining Gateway and should be avoided from a visual and best practice perspective.
Visual issues Terminating a Gated flow
This section has been added because the understanding of the operation of a Process can be made easier purely by paying attention to the visual approach to the layout. The following shows this type of re-evaluation of the visualisation of a Process.
Visual issues Terminating a task (Not Best Practice)
In the below example we take the Process View shown in the Method of terminating a branch from an Exclusive Gateway – (Not Best Practice) section where Task 5 is terminated on execution.
However, the process has been modified as it has been realised that Task 1 also needs to be separately terminated. This could be connected as shown in the same section but this results in the crossing of paths. This is not incorrect but adds to confusion over the point-to-point connection of the Tasks.
Visual Issues Terminating Task Resolution
In this next diagram the same approach has been taken to task 1 as applied with Task 5 where the Process is terminated directly after Task 1 executes.
Simply redrawing this process, as in the below example, adds to the visual flow of the complete Process. Here it can be simply visualised that the top split continues to Task 3 and subsequently to the end point, whilst the lower two elements can easily be seen as terminating directly after the completing of these tasks.
In this example the main flow (at the top) becomes the focus visually where as the earlier terminations appear as separate secondary elements.
This simple segregation of the Process structure allows the viewer a more intuitive view of the process.