Multiple tokens in OR construct

Hi everybody,

I have a question for which I was unable to find an answer in the specs.

I have a block-based construct (3 blocks/ main arcs) that starts with an OR split and ends with an OR join. In a regular scenario, any activation of an outgoing arc in the OR split will trigger an activation of the corresponding incoming arc into the OR join.

However, our scenario assumes that we may trigger multiple activations on certain arcs. Let’s say a possible scenario is that we will have, at any point in time, 3 tokens on the first block (arc), 2 tokens on the second block (arc) and 1 token on the third block (arc).

The question is how will the OR join behave in the Camunda engine? Will it wait to consume the 6 active tokens before moving on or will it consume just 1 token from each block and then just deadlock?

Many thanks for your help!


Hi Bogdan,

If you run this process model in Camunda:

the three conditions will be evaluated as the token arrives in the or-split. The tasks will be activated once for each matching condition.

If you mark task 1 to task 3 as multi-instance, each task is completed, if all instances of the task are completed. The join is activated afterwards.

Hope this helps,


Hi Ingo, thanks a lot for your kind answer. I know the behavior of MI activities and it is indeed as you describe it.

But let’s consider a non-MI case, where Task 1 is linked to a intermediary catching message event that triggers the Task 1 to have 2 tokens if it has not been executed yet. My question is - what happens to that extra token, does it get locked at the OR join?

I know it’s an unorthodox construction, but - what if?


Hi Bogdan,

if you model is this way:

the extra token is stopped in the joining or-gateway and you get a deadlock.



Thanks Ingo, this is clear.

Let me up it one notch :slight_smile:

What if you have 2 tokens in task 1, 3 tokens in task 2, 1 token in task 3? Can they all get consumed at once simply because the OR join has all three incoming arcs activated?

Or are they consumed in 1-1-1 triples?


Hi Bogdan,

I had a look at the InclusiveGatewayActivityBehavior and the InclusiveGatewayTest and theoretically, a 2-1-0 incoming could be sufficent to leave the joining gateway.

But how do you create the additional tokens? If you use the start-event from my former example, you will get a new process instance instead of and addition token?

Cheers, Ingo

Hi Ingo,

thanks for the quality discussion and for the links!

What we want to implement (in a contracted form) is the 3-way match of the same Order, where we could have multiple partial Goods Receipts and multiple partial Invoices (GR and Inv being verified on separate arcs of an OR split). You can have a likely scenario where, while a GR is being processed by the user, another GR is incoming and awaits validation in the same task and maybe only one Invoice is being evaluated by another user (or has already been evaluated and awaits global reconciliation after the OR join).

I know we can most likely model this by separate processes which then we orchestrate via messages whose payload is the other ID.

But we wanted to explore if we could contract this in one single process instance, which acts as an overall case instance. Probably too ambitious, but still interesting!


hi there :slight_smile:

i just came across something similar: i try to have a process runnning a subprocess in parallel for a collection of items. so that multiple tokens can be active at the same time. that works fine.
the items gets exported to a third party system and then wait for it to reply, which can take up to 2 weeks. in the meanwhile, mails should be triggered when replies come in - therefore i created the subprocess border escalation catch event.
but i only want to send one mail once a day - so it is kind of the same problem: i can have multiple instances in the shown timer event, but before proceeding i somehow want to merge these tokens before sending the actual mail…

any hints on this?

Hi Johannes,

you can model the condition “send only one mail once a day” using a process variable and a gateways. The process variable stores the latest sent date. Before send the mail, you check the variable and ignore the event if you already sent the mail.

Alternatively, you could have an event subprocess with a timer start event which starts the subprocess every day. When the subprocess is started, it waits for the escalation event and send the mail. The subprocess ends after processed the first event.

Best regards,