Exclusive gateways (XOR) and tokens

First part of the series covered simple case of sequential processes.

Now, it’s time to move to something more complicated and useful in real-life scenarios: handling various process paths with gateways. This part will show you how tokens behave in processes with XOR (exclusive) gateways.

Exclusive gateways
Exclusive gateways (often called XOR) are used when process splits into several paths and only one of them can be active. Important thing is that in this case tokens are not duplicated, so the gateway only routes the token to a proper path (depending on conditions defined for each of the sequence flows).

Simple example can be e.g. sales process where customer either accepts the offer as it is, rejects it fully or asks for negotiations 🙂

In this case name of the gateway could be “Customer decision?” and conditions for the process paths outgoing from this gateway: “offer accepted”, “offer rejected”, “negotiations requested”.

As already mentioned, conditions should not overlap. It also makes sense to check that we did not omit any option since our process would get stuck if no condition we provided was true for this case (we can safeguard against this using default sequence flow described in a section for Inclusive gateway/OR).

Since there is no token duplication, it is possible to leave only “opening” exclusive gateway or close it with additional one – meaning will be the same.

I personally prefer the first option since it is more compact, but I know many organizations which prefer second option stating that having some additional elements in a diagram is a small price for increased clarity. This is something I see more often when process modellers have strong academia background or when they are from IT. Perhaps this recalls them coding where opening and closing brackets is really important?

Below you can see example of a process with XOR gateway in two options – with closing gateway and without.

Now, it’s time for something more complex – process instances. While process diagram represents all possible ways in which a process can run, an instance is a specific process run.

For instance 😉 – there can be one standard process definition for handling insurance claims (=process diagram), but actual steps performed while handling claim reported by Alice Smith (instance #1) may be different from the steps performed while handling claim reported by Bob Jones (instance #2) and so on.

Useful tool for such analysis is a process log which shows which steps were performed in a process instance (possibly along with other information such as time etc.). You can think of a process log as a diary of a process 😉 Process logs are very important in so called process mining, but this is a different story…

How could the process log showing different process instances look like? As you can see in an example below instance #1 could be ABEF, instance #2 ACEF, instance #3 ABEF (again – let’s assume this is our expected way of running a process aka happy path), instance #4 ACEF and so on…

So far our examples assumed that paths split and afterwards merge. However in reality XOR gateways often lead to different endings of a process. You can see this on a graphic below.

But what about processes where tokens get duplicated and several process paths can happen at the same time? This is something we will cover in part 3!