Whenever the conditions on the other paths aren't met, the instance will proceed via the Default Flow.
In other words, if none of the conditions for the outgoing sequence flows are met, the Default Flow provides an alternative route for the process to follow.
This ensures that the process can still progress even if none of the explicitly defined conditions are satisfied, providing a fallback option for handling unexpected scenarios.
For example, consider a scenario where multiple variables are involved in a process, and it's possible for more than one variable to be true in the process context (see image 2 above).
To guarantee that only one condition will be true, you can use additional expressions, such as "voucher == false" to specify distinct paths for each condition.
This ensures that only one branch of the expression will be true, preventing conflicts and providing a clear direction for the process flow (see image 3 above).
In cases where there might be more options to evaluate later, and all options will follow the same route, consider using a Default Flow.
This can be particularly useful when dealing with scenarios where additional payment gateways might be added in the future, but they will all follow the same processing path.
You won't have to modify the expression whenever new payment gateways are added, only if the underlying logic changes (see image 4 above).
To join or merge an Exclusive Gateway (see Image 1) is not mandatory; it depends on the specific scenario.
When the process encounters the Exclusive Merge, only one of the incoming sequence flows will be activated, indicating which path was completed first or satisfied its specific condition.
While the Exclusive Merge is commonly used alongside the Exclusive Gateway, it is also compatible with other gateway types in BPMN.
It serves as a valuable mechanism for synchronizing and consolidating multiple parallel paths, ensuring that only one path is followed based on the given conditions.
At least one path should be true for the process to continue.
Unlike an Exclusive Gateway, where only one path can be taken based on the conditions, the Inclusive Gateway evaluates all incoming sequence flows and enables all the paths for which the conditions are met.
The process may diverge into multiple paths, each representing different job categories.
For example, some candidates may possess strong problem-solving skills but lack coding proficiency, making them suitable for specific departments that require problem-solving expertise.
On the other hand, other candidates might have a combination of problem-solving and coding skills, making them eligible for multiple departments where these skills are essential; this means the result is not exclusive to one path.
The purpose of an Inclusive Gateway merge is to consolidate multiple parallel paths that were previously split.
Unlike an Exclusive Gateway merge, which selects only one path based on conditions, the Inclusive Gateway merge evaluates all incoming sequence flows and allows all paths with true conditions to proceed.
This means that if multiple paths were activated during the parallel execution, all these paths will converge.
It's important to note that the use of an Inclusive Gateway and its corresponding merge is not mandatory in a process.
They can be used independently, depending on the specific scenario and process requirements.
In some cases, only the Inclusive Gateway might be used to split the flow into multiple paths based on different conditions without necessarily requiring a merge later in the process.
Similarly, the Inclusive Gateway merge can be used without an Inclusive Gateway to consolidate parallel paths from other types of gateways, or even from different parts of the process.
Note that the behavior for a parallel join, also known as a Parallel Gateway merge, is to synchronize and consolidate multiple parallel paths into a single flow.
When the process flow reaches the parallel join, it evaluates the completion of all incoming sequence flows from the corresponding parallel split.
It ensures that all parallel paths have completed their execution before the process continues along the single outgoing sequence flow after the join.
|  | **Name:** Update Customer Information | A descriptive name given to the element, providing a human-readable label or title. |
|  | **ID:** Example - updateCustomerInformation | An identifier used to uniquely identify the element within the BPMN model. |
|  | **Element Documentation:** URL, Raw Data, Plain Text | Additional information or documentation related to the element, such as URLs, plain text, or raw data. |
|  | **Condition:** payment_method == "credit_card" | Python expression. Note that multiple conditions can be strung together using AND/OR. |
