Gateways - Control the Process Flow

Objective

After completing this lesson, you will be able to explain how to split and merge process flows

Gateways - Control the Process Flow

Control the process flow!

The Exclusive Gateway (XOR)

Usually, in a business process, not all tasks are always executed. In most business scenarios, decisions are part of the process to control how to proceed in certain cases. These scenarios obviously affect the design and structure of your process model. First, this means that within the process model we have to split up the sequence flow into different paths.

A diagram example depicting the process of satisfying hunger. It starts with a start event labeled as Hungry, followed by three tasks: Buy groceries, Prepare meal, and Eat meal. Ends with an end event, Not hungry anymore.

In the previous lesson, we learned how to use events and tasks to create our first own process model. We connected a start event that represented a need, hunger, with several activities, buying, preparing, and eating a meal, to reach the satisfying feeling no longer being hungry.

However, wouldn't it be even more satisfying to prepare and eat a meal of our choice?

Exclusive Gateway (XOR)

Diagram illustrating a decision-making process for a meal preparation. The process start event is Hungry, leading to Select meal. A decision point Which meal? splits the process flow into three options: Cook Pasta, Prepare Salad, and Grill Steak, each leading to their respective end events: Pasta is cooked, Salad is prepared, and Steak is grilled.

Using the Exclusive Gateway for Splitting (XOR Split)

Based on our previous meal example, let's assume we have different groceries at home to cook something delicious. Driven by hunger, we must now decide about what we want to eat.

The exclusive gateway reads out the result of our decision (select meal) to guide us to the next task. The process flow is being split up into several ones but only one path can be chosen at a time.

In other words: this is an either/or decision.

Reaching the Process Goal

The steps of eating the prepared food are added to the preceding diagram. So, we're not hungry anymore.

Add Missing Tasks

You might have noticed that there was an important factor missing in our previous example - we never ate, as the process has ended after our meal has been prepared. Our initial goal (being not hungry anymore) was not fulfilled. To be more precise: The process is not modeled completely.

So, let's add the tasks to ensure that at the end of the process, we're not hungry anymore.

Merging Process Branches

The steps Cook Pasta, Prepare Salad, and Grill Steak are merged into one step: Eat meal.

Using the Exclusive Gateway for Merging (XOR Join)

Our previous solution at least ensures we reach our goal, but increases the complexity of our process as:

  • the "Eat meal" task does not depend on the meals, but applies the same to all different meals.
  • we created the same process goal (end event) multiple times for each branch.

To avoid the problems above, we must find a way of merging all split branches with the original process flow. Fortunately, we can use the exclusive gateway again, as demonstrated in the image above, Using the Exclusive Gateway for Merging (XOR Join).

Conclusion

When you split with it, merge with it.

Exclusive gateways:

  • have a splitting behavior to route to the next required task, based on a certain condition.
  • have a merging behavior, to join different branches in the process with the main flow.
  • must be used pairwise. That means, if a process flow has been split into several branches with an XOR gateway, the joining gateway must also be an XOR gateway.
  • have exceptions to this. If the sequence flows go to different end events, a splitting gateway does not have to be merged. This means that the single paths are moved into different paths and do not have to be merged anymore.

Note

The BPMN standard also allows exclusive gateways to be used without having to merge them again. Therefore, this is not a syntax error. However, it is recommended to merge the sequence flows again with an exclusive gateway, because this way the diagram remains well-structured and errors can be avoided.

Using Exclusive Gateways as Standalone Decisions

Exclusive gateways are not decisions. Why? Because they are not tasks but rather a control element to route the next task, based on the result of a decision that was made previously.

The exclusive gateway itself is not a decision.

Select meal is a task that must be completed before any of the outgoing paths can be selected at the XOR gateway.

The exclusive gateway reads the result of the decision that was made in the previous task. Either grill or cook the pasta.

A Decision Is Missing.

Diagram representing a missing decision in the process. An explanation is given in the following text.

Gateways Don't Replace (Decision) Tasks

Although it looks like there is a decision in this process example, in fact, there is none. A gateway alone is stateless as it's only an instrument to control the next step based on information. In contrast to tasks, a person cannot "own" (be responsible for) a gateway.

Referring to the process example above, it means:

  • The actual decision (select meal) is missing and hence never made.
  • The information of a selected meal is "simply available" from the beginning but is not determined as part of the process.
  • Although the XOR gateway is in Tim's lane, he is not responsible for the "routing", as a gateway is just a stateless instrument. Furthermore, it doesn't matter in which lane a gateway is placed. It's only important to whom the next task is assigned.

Getting Back to Our Token Concept

Let's have a look how the process is applied when using splitting and merging exclusive gateways.

Naming Convention for XOR Gateways

As we have seen with tasks and events, elements in BPMN do follow a certain naming convention, in order to understand them quickly and intuitively.

XOR gateways and in particular gateways that handle results/conditions in a process, also have naming conventions. These are:

  1. Exclusive gateways must be labeled with a question.
  2. The outgoing conditions (sequence flows) must be labeled with the answer to the question.
  3. All outgoing conditions must exclude each other. For example, yes/no.
  4. Merging Gateways are never labeled.
Flow diagrams representing the naming conventions that are outlined in the preceding text.

Key Takeaways - XOR Gateways

1 - Pairwise usage: XOR gateways should be used pairwise, if the branches are going to be merged with the main process flow. 2 - Gateways are not a decision: XOR gateways never represent a decision – but handle the result of a decision which have been made previously and route to the next task. 3 - Naming convention: XOR gateways should be labeled with a question, which is answered by the outgoing sequence flows (conditions).

The Parallel Gateway (AND)

Texts can be executed in parallel, increasing the efficiency of the entire business process.

Tasks can be executed in parallel, increasing the efficiency of the entire business process.

Today, most business processes include multiple tasks, which are executed independently of each other by different departments / people. The process can only continue past a certain point after certain tasks have been executed. To model such a behavior in processes, we can use the parallel gateway (also called the "AND" gateway).

Diagram representing a parallel gateway, as described in the following text.

Executing Tasks Independently of Each Other

In the previous example, we didn't have a choice of selecting and eating multiple dishes at the same time. What do we actually do when we want a salad as a side dish?

To ensure that we can eat a salad AND a steak ,let's add a parallel gateway to our process.

With the usage of the AND gateway, there are some considerations:

  1. AND-Split: We always have to prepare and eat both - there is no choice anymore.
  2. AND-Join: We can only start eating after both have been prepared.

Summarizing the Process Behavior

With parallel gateways, after both tasks are completed independently, the process continues. The emerging parallel gateway synchronizes all token paths.

Applying the Token Concept

AND Gateways - and their Impact on Cycle Times

The process example provided shows the BPMN element (text) annotation on the task, which we have used to document the execution time. Text annotations can be used at any time on any BPMN element to provide helpful hints/information - but they must be used rather rarely to not overload the process model.

Distributed Tasks by Multiple Resources

In this example, sequential tasks are carried out by one resource. The process is explained in the following text.

The number of resources conducting a process becomes crucial whenever tasks actually need to be executed in parallel. One person cannot perform multiple tasks at once, even if it has been modeled as such. The point is, when assigning parallel tasks to only one responsibility, the order of execution is not important. Let's use a more visual explanation:

Tim is acting alone:

  • The cycle time cannot be reduced, as Tim has to do everything alone in a sequential order.
  • Even if tasks are assigned in parallel, Tim cannot do both at the same time - but he can at least decide which task to start with.
In this example, parallel tasks are carried out by multiple resources (Tim and Robert).

Tim gets supported by Robert:

  • While Tim takes care the steak does not get burned, Robert prepares the salad in the meantime.
  • Both tasks must be completed before they both can start eating together.

Note

Tasks connected to a parallel gateway don't have to start at the same time. The parallel gateway just ensures that the connected tasks are executed independently of each other - and are also completed, before the process can be continued.
1 - Splitting and Merging: The Parallel Gateway activates all outgoing sequence flows and generates separate tokens for them. In merging behaviors, they wait for all tokens to get merged to continue. 2 - Parallel execution: If the tasks can be assigned to multiple resources, they can work in parallel. One person cannot perform multiple tasks at the same time. 3 - Naming convention: Parallel gateways and outgoing sequence flows are not named, as they just split up the process flow into multiple parallel branches.

The Inclusive Gateway (OR)

Sometimes, having only one option to choose from is not enough.

Sometimes, business tasks require flexibility.

Process Example

Imagine you're working at a telecommunication provider, where the customer can add different products for an extra charge to the main contract for internet and phone. Those can be:

  • an internet security package.
  • an additional router for a better Wi-Fi connection.
  • an additional mobile hotspot to connect from anywhere.

The business process should be designed so that all of these options can be chosen and the related business tasks are executed, based on the chosen set of options. They can't be mandatory, as not every customer want to add all three options every time to the contract. They also can't be exclusive as different products can always be combined.

The Inclusive Gateway (also called OR Gateway) allows modeling the situations described previously. Or more specifically, to model business scenarios, where different options can be combined, while ensuring that at least one option has been chosen.

Note

Although the "o" in the gateway stands for OR, you can also think of "options". This way, it's easier to remember its usage (as OR can also be misinterpreted as XOR).

How Does the OR Gateway Work in Detail?

The splitting inclusive gateway allows to combine different options, but at least one must be chosen to create a token. the merging inclusive gateway either synchronizes all tokens created in case multiple options have been chosen, or passes the only existing token forward.

This gateway is the most flexible one, as it behaves as a mix of exclusive and parallel gateway.

On the splitting side, it can either trigger only one outgoing sequence flow (like an XOR) or multiple ones at the same time (like an AND). It can also combine only a few of all possible conditions - or even all of them. This aspect of flexibility might be difficult to understand just by looking at the OR gateway in a process model. However, it can be helpful in certain scenarios to replace a set of nested XOR and AND gateways.

On the merging side, the OR gateway can either synchronize different tokens (like an AND) or just passes a token forward, if there are no others (like an XOR). The specialty is, it doesn't wait for tokens on ALL incoming sequence flows (as the AND does) but only for the ones that are actually on their way.

Shared Tasks - Depending on the Case

Flow diagram representing optional tasks with multiple resources. The options are explained in the following text.

Optional Tasks

While for some processes, we know all the responsible roles and personas ahead of time, for other processes the responsible parties can vary, depending on the situation.

Looking at the process below, we can say:

  • All members choose a meal together (although Tim makes sure they all come together as a main driver of this task).
  • Example Case A: They all agree on having pasta and salad. That must be prepared by Tim and Robert.
  • Example Case B: They all agree on having steak and salad. That must be prepared by Sarah and Robert.
  • Example Case C: They all agree on just having pasta. As a pasta expert, Tim takes care of cooking a delicious pasta meal for the group.
  • In the end, Tim makes sure that they all eat together.

Applying the Token Concept

The following video shows how the tokens are created, based on a certain case (steak and salad).

Key Takeaways - Inclusive Gateway

1 - Splitting and Merging: One, multiple, or all outgoing sequence flows can be triggered. In return, the merging OR gateway synchronizes multiple tokens or sends one forward, if only one exists. 2 - Parallel execution: It also enables a parallel execution but this depends on the case, if multiple sequence flows are triggered – and if multiple resources are assigned. 3 - Naming convention: Equal to the XOR gateway, the OR gateway should be named with a general question, which is answered by the outgoing “options”. 4- Hidden complexity: The entire number of possible combinations is not visible in the process (and hard to grasp for new process viewers).

Now, it's time to have a closer look at common mistakes in practice, which might occur when the wrong combination of Gateways have been used.

Avoiding Unintended Process Flows

Wrong gateway combinations can lead to unintended process flows.

How can unintended process flows happen when we've already learned how to control them by gateways? Normally, this does not happen if you consider the rules for splitting paths, merging flows correctly, using gateways, always pairwise, and follow the naming convention. However, we are humans and learning by making mistakes is in our nature - especially when complex business processes must be modeled. Fortunately, we can show you the common pitfalls and how to avoid them.

The token concept helps us in analyzing incorrect process behavior and to correct process flows, so the tokens don't get stuck in the process.

Incorrect Process Flows

Flow diagram representing deadlocks in the process. The flow is explained in the following text.

Deadlocks

Deadlocks can occur when a parallel merging gateway waits for multiple tokens to synchronize but at least one token doesn't exist. Sounds weird? Check the process example above to figure out how this can happen (by accident).

Explanation:

  • The parallel splitting gateway creates two tokens (green flow)
  • Token 1 traverses "prepare shipment" and arrives at the parallel merging gateway (to get synchronized). Token 2 traverses "check customer status", "offer premium membership" and arrives at the parallel merging gateway (to get synchronized)

Problem: The parallel merging gateway expects a third token (red flow) as it always awaits a token on every incoming sequence flow. Unfortunately, this token doesn't exist - so the process gets stuck at this point (Deadlock).

The deadlock in the flow is resolved, as explained in the following text.

Add the missing XOR Join

To fix the problem, we must add the missing exclusive gateway to join the two sequence flows into one.

Multiple Task Execution

A multi-merge is show in the process flow, with three tokens merging.

Multi-Merges

Multi-merges are not necessarily an error in terms of BPMN - but they usually create an unintended process behavior. They can occur when multiple tokens are not synchronized (to one) - or in other words: If a parallel merging gateway is missing.

Explanation:

  • The parallel splitting gateway creates two tokens (green flow).
  • Token 1 traverses "prepare shipment" and arrives at the exclusive merging gateway - and is forwarded to "send order". Token 2 traverses "check customer status", "offer premium membership" and arrives at the exclusive merging gateway - and is forwarded to "send order".

Problem: Without synchronizing the tokens created by the parallel split, the task "send order" is executed twice, and they also reach the end event twice.

The multi-merge issue is resolved, as explained in the following text.

Add the missing AND Join

To fix the problem, we must add the missing parallel gateway to synchronize the two tokens in the process into one. To finally send the order, the synchronized token is forwarded.

Note

The Graphical Editor in SAP Signavio Process Manager automatically checks if your process contains a deadlock or a multi-merge, and shows exactly where in your process it is.

Modeling Exercise - Order Processing (Part 1)

Order Processing: MyStore Inc. Process documentation for a fictional enterprise.

This is an active process modeling exercise, to be done in SAP Signavio Process Manager. If you already have a license, you can start immediately. If not, you can also register for a 30-day trial version for free and start in three minutes.

Nothe that all three modeling exercises in the course are optional. However, the exercises give you the chance to apply your knowledge and to become familiar with the Graphical Editor of the SAP Signavio Process Manager.

Check out the eLearning course SIG120 Introduction to SAP Signavio Process Manager if not done yet, to have all necessary skills for completing the exercises with the Graphical Editor.

Feel free to register for a 30-day trial version and explore the SAP Signavio Process Manager. No credit card / payment required. Link: Register

Case Study.

Background

MyStore Inc. is a medium-sized mail order company. Due to the growing number of orders, the management has decided to document the business process of stock-to-delivery. Among other reasons, they also expect an improvement of onboarding new employees by providing transparent knowledge about internal processes.

If MyStore Inc. receives an order, an employee from the order acceptance team first enters the order data. The customer receives an order confirmation afterwards. An employee from the warehouse team then checks the delivery priority for the order.

If the customer has a premium status, the goods are prepared for express shipment, otherwise for regular standard shipment.

While all preparations for the shipment are being made, the invoice is created by the order acceptance team. Finally, the invoice is sent to the customer by the order acceptance team and the order gets shipped by the warehouse team.

Assignment

  • Transform the "order processing" description into a compliant BPMN 2.0 model.
  • Only use the elements that you have already learned and model the perspective of the MyStore Inc. You don't need to include external process participants yet.
  • Estimated time effort: Approximately 45 minutes.

Modeling Tips

Modeling Tip 1: At least one XOR and one AND gateway are required to model the process.

Modeling Tip 2: Consider this blank shape model as a design orientation.

Diagram of a blank shape model that you use in this exercise.
Double-check your answer.

When you think that you have finished, check your solution again for syntax, semantics, and naming convention issues. Also, think about a user-friendly, or readable look and feel for your diagram.

Note

There are different solutions for this exercise. However, you must cover the same subject matters. Of course, the names of individual elements and the overall design may differ slightly.

When you are ready, view the sample solution and compare it with your own.

Solution to the Order Processing Exercise - Part 1

Sample solution from order received to order sent, in two swim lanes: Order acceptance and Warehouse.

Log in to track your progress & complete quizzes