BPMN 2.0 parallel converging gateway

I have a Bpmn process map.

Let’s say it has 20 steps.

I have a decision (exclusive) gate after step 9. If the decision is ‘no’ I must perform 2 activities in parallel , however these activities both go back to different parts of the processs - one to step 7 and another to step 3 (both happening at same time).

I have used 2 link out events after the parallel gateway with 2 catch link events - one goes to step 7 and other step 3. Where should I put converging parallel gateway?

What it the problem?

This is a very tricky construct that is not easy to model. The no branch of your exclusive gate would necessarily lead to a parallel gateway. Upon an incoming token, it would send an outgoing token to each of its destination, meaning at the same time at step 3 and at step 7. The problem is that you'd have a kind of trafic jam of tokens:

• the token at step 3 would take the route to step 9 again
• at the same time the token at step 3 would take the route again
• you would have at some moment to join the parallel flows with a join gateway, making 1 outgoing token of two parallel incoming tokens
• unfortunately, assuming that both flows are expected to go up to step 9 again, you would have no way to distinguish the normal token and the subsequent parallel tokens, making it impossible to join the parallel flows, hence having a broken situation.

This would require a substantial reengineering of your model, if you want something legit and at the same time readable.

Alternative 1: Duplicate relevant steps in parallel branches

If the initial flow is sequential and very different from the parallel branching, the easiest and most readable way would be to have a parallel gateway after the no fllowing step 9, and duplicate the steps in two parallel branches, that would then be joined again with a join gateway.

Pro:

• easy to model
• very easy to read

Cons:

• duplication instead of DRY
• enven more complex process

Alternative 2: parallelise step 3 and 7 from start?

It's difficult to tell from your narrative. But it is not clear if step 3 and 7 do have to be one after the other in a sequential order in the initial flow. Is it by accident or by intent?

If it is by accident, i.e. if in reality 3 and 7 could already be done in parallel but mostly are performed in sequence, then reengineer your flow by parallelising step 3 (maybe with 4,5, and 6) and step 7, and joining the parallel flows properly. The fact that they are modeled as parallel, does not prevent them from being done in practice one after the other. The decision after step 9 would then simply branch on the initial parallel gateway.

Pro:

• model is more accurate than before
• the parallel art is very readable

Cons:

• only possible if the initial flow can be paralleled

Alternative 3: Subprocesses (variant of 1)

This is a variant of alternative 1. As the subchains to duplicate may be complex, and moreover, both subchains must be kept in sync when maintained, you could consider simplifying your diagram for the initial part, putting the detailed steps (e.g. 3 to 6 and 7 to 8) into subprocesses.

The simple parallel flow would then just duplicate the subprocess box, keeping the diagram relatively simple and duplicating the minimum possible.

Pro:

• Simpler diagram
• Even easier to read
• Consistency when subprocesses are updated

Cons:

• Need to introduce the subprocesses.