Inclusive gateways (OR) and tokens

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.