BPMN Category

This post is a part four of the series about token and process flows in BPMN.
So far, we covered the simple flow (part 1), situations where only one of the alternative paths could be selected (part 2), as well as cases when all paths outgoing from a parallel gateway need to complete before the process can continue after the merge (part 3). Now, it’s time to tackle more sophisticated situations.

Inclusive gateways

Inclusive gateways (commonly called OR) can be used to show that certain paths will always happen and others only sometimes – depending on certain conditions. You could say that OR gateway behaves like a (compact) mix of XOR and AND gateways.

It’s easy to recognize the OR gateways since they are diamonds with a circle inside (you can think that this marker is a slightly distorted “O”).

Let’s start by comparing OR gateway with XOR.

For XOR gateway you could have many paths outgoing from the gateway. The same applies to OR gateway – there can be 2, 3, or more paths.

Now, let’s take a look at the conditions on the outgoing paths.

For XOR gateway token would take a first path with a condition which is true. So while in practice we would expect the conditions to be mutually exclusive, in theory it could happen that two of them are true at the same time. However, XOR sends a token to a first path which has a true condition, so only one of the paths can be selected.

For OR gateway situation is different. Conditions of all paths are checked and each path which has a true condition gets a token. That’s why we will normally use a pair of OR gateways – for splitting and merging – just like for AND gateways.

Please take a look at the image below and compare differences between XOR and OR gateways.

How would your process log look like if we would have a hot (but not sunny) weather? For both types of gateways the result would be the same: ABEF.

To make it easier to remember let’s assume that it is a process of preparations for a walk and that task B is “Take a bottle of water”.

What about sunny, but not hot weather? Again, both are identical and we get ACEF. Task C could be “Take a sunscreen”.

And weather neither hot nor sunny will give us ADEF in both options. Task D could be “Take a hoodie”.

All those examples have only one token in a process instance, so we do not need any synchronization.

But if our weather is hot and sunny at the same time we will have a different situation.

Our XOR gateway cannot handle it well and (assuming the top path is checked first) we will have ABEF, so the same option as for the hot, but not sunny days. In other words, we will take a bottle of water, but not a sunscreen. Ouch! We might get a sunburn.

Luckily OR gateway comes to the rescue, and we will have ABCEF, which means we will not leave home without a bottle of water and sunscreen. Therefore we will be safe both from sunburn and dehydration 😉

Now, let’s see how do AND and OR gateways compare. As we already discussed, OR gateways allow you to duplicate tokens, just like AND gateways. However, they allow you to send tokens only to selected paths and have a smarter synchronization.

Why smarter? Merging AND gateway waits for tokens from all incoming flows, while merging OR knows which paths were active. So we can easily leave home without hoodie if it is hot 🙂

Last interesting feature of OR gateways which is similar to AND gateways is that you can have paths without a condition. Since they are always valid, they will also always get a token.

Please take a look at the animation below (taken from my course):

If you are worried that readers of your diagrams may not know it, you can always call those paths “always” 🙂

On the other hand – if you are feeling geeky and names of paths like “Neither hot nor sunny” don’t sound technical enough for something which basically reminds you ELSE clause from programming you can mark such path as a “Default Sequence Flow”. It will get a nice slash at the beginning.

Please note that “default” does not mean it is most probable, expected, most profitable etc. path. It only means that token will take this path if no other path has a valid condition.

I hope you enjoyed this quick overview of most common gateways in BPMN. Stay tuned for a new post – this time about Tasks.

PS. If you are curious – there are more gateways in BPMN, but the ones we covered so far should be sufficient for the most of you.

This is a third part of the series about tokens in BPMN. The first part was about basics and simple flow, the second one was about exclusive gateways (XOR). This time we will cover cases when our process has parallel paths.

Parallel gateways

Parallel gateways (commonly named AND) allow you to show that there are certain things in your process that need to happen, but they do not need to be performed sequentially. Like every gateway, it has a diamond shape, but with a + marker inside.

They can be performed at the same time e.g. by different people or some skilled multitasker 😉 but this is not required.

Important thing is that Parallel gateway will “copy” an incoming token, so that every outgoing Sequence Flow gets one. Those tokens flow independently through your process, so usually we need a second Parallel gateway to combine them again into a single token. This is called synchronization.

Why do we need synchronizations? There are several reasons. Technical reason: if you do not synchronize tokens, they will continue flowing and activating subsequent Activities. Business reason: usually we need AND gateways to show that some things need to be done before something else can happen.

Let’s imagine a simple process of preparing a report. After an initial analysis of a request we need some input from 3 teams: finance, marketing, and sales. It does not matter who sends us input first: finance, marketing, or sales. We need them all. After we have those 3 elements we can prepare a final report and send it.

Does it make sense to make a report on a basis of data from sales only? Probably not. Would the recipients be happy if we would be sending them 3 separate reports instead of one consolidated document? Unlikely. That’s why in 99% of cases AND gateways are used in pairs: one for splitting and one for synchronizing paths.

In case you are wondering what happens in this 1% when there is no synchronizing AND gateway: tokens flow independently, possibly causing some tasks to happen few times (so in an example above we could have a log ABEFCEFDEF). Only after the last token reaches end event process instance ends (unless you use terminate end event of course).

Since every path will get a token (we do not check conditions as we did in XOR) usually it does not make sense to add names to AND gateways.

Now, you may be wondering – would it be possible to have some paths which always happen and others which happen when certain conditions are true? Spoiler alert: you can do it with Inclusive gateways (OR), which we will cover in part 4.