Parallel gateways (AND) and tokens

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.