What is the correct way to model converging inclusive gateways?

In the version 8 docs for inclusive gateways it states that Camunda “only supports the diverging (i.e. splitting, forking) inclusive gateway. It does not yet support the converging (i.e. merging, joining) inclusive gateway”. What is the appropriate way to model a section of process similar to the following?

image

Hello! All good?

I currently use Camunda 7, I’m not very used to 8… But according to this part of the documentation:

an “Inclusive gateway” can be used to separate the “tokens” and then use a "parallel gateway to merge and then an "exclusive gateway to close and continue the flow.

I believe you should do the following in your process flow:

hope this helps!

Regards.
William Robert Alves

Thank you! That makes sense when you visualize it like that. It wasn’t entirely clear in my mind what was meant by that comment in the docs.

1 Like

Hi @nickw

I would be careful using this pattern it could cause a deadlock.
The parallel gateway is always going to wait for the number of tokens equal to the sequence flows pointing at it. so in a case where the OR gateway doesn’t send tokens through all sequence flows the process will deadlock on the parallel gateway like this:

2 Likes

Mr. @Niall is absolutely right… if the fact that the tokens will always be divided into 2 is not right, your flow will be stuck in the parallel gateway.

So if your instance goes through only ONE SINGLE PATH, we will have problems…

But if your flow is always divided into 2 or more… I think you won’t have any problems.

William Robert Alves

1 Like

Elsewhere on the forum, I’ve seen the recommendation to model it as a chained Parallel then Exclusive gateway combination.

— <+ > — < x > – [ Optional Task ] – < x -Join, connect with a bypass of optional task > – < + >

2 Likes

Hi @nickw,

As suggested by @GotnOGuts, an Inclusive gateway can be replaced by a combination of exclusive and parallel gateways.

image

4 Likes