@pitu72 using the inclusive gateway as the join, it will only wait for the flows that active:
from the docs:
join: all concurrent executions arriving at the inclusive gateway wait at the gateway until an execution has arrived for each of the incoming sequence flows that have a process token. This is an important difference to the parallel gateway. So in other words, the inclusive gateway will only wait for the incoming sequence flows that are executed. After the join, the process continues past the joining inclusive gateway.
So if if Step 3 is always executed, and then Step 1 is only executed, then the flow will only complete once the Step 1 and Step 3 are completed. The tokens will wait at the joining gateway until the flows are completed.
So regardless of which steps you take, the will always be “synchronized”/joined at the joining gateway (second gateway). If you need more work to occur after step 3 you can follow the work of @Webcyberrob, but you dont even need the parallel gateways.
The flow you have described is all of the logical outcomes, but it seems you are mapping it like a matrix of possibilities rather than a BPMN problem and what the camunda engine offers (hence the use of the inclusive gateway’s joining capability)