The General Synchronizing Merge (workflow pattern 37 in the van der Aalst catalogue) merges branches that were split by an OR (inclusive) gateway: the merge must wait for every branch that was actually activated and continue exactly once - even when the number of active branches is decided at run time, and even when branches contain loops so that the "how many are still coming" question cannot be answered locally.
In IBM BPM / BAW the inclusive gateway (OR gateway) implements it for the common case: a diverging OR gateway activates the branches whose conditions are true, and the converging OR gateway of the same pair waits for all tokens that can still arrive on its incoming flows, then emits one token. The engine tracks the tokens produced by the diverging gateway, so you get the synchronizing merge without counting. The "general" variant (loops feeding back into branches, branches created by different splits) is not expressible with one gateway; model it explicitly:
BPD: (OR split "Which checks?") -> [Credit check] ---\
-> [Fraud check] ----> (OR join) -> [Decide]
-> [Manual review] ---/
the OR join waits for exactly the activated branches; unused branches do not block
General case (dynamic number of branches, loops): use a counter variable
tw.local.expected = number of branches started (set at the split);
each branch ends with a script: tw.local.done = tw.local.done + 1;
an exclusive gateway after each branch: tw.local.done < tw.local.expected ? (end this token) : -> [Continue]
(or an event sub-process that collects "branch done" messages until done == expected)Alternatives when the branches are many and dynamic: a multi-instance activity (BAW: "run for each" with the sub-process / linked process) whose completion condition synchronises automatically - the cleanest implementation of "wait for all that were started".
References