Gateways

Parallel Event-Based Gateway

A rare start-position variant of the event-based gateway: the process instance is created only after ALL the events following it have occurred. Diamond with a plus inside a double circle.

Where the regular event-based gateway races events (first one wins), the parallel event-based gateway — used to instantiate a process — collects them: every event after the gateway must occur (in any order) before the instance starts. It is the gateway counterpart of the Parallel Multiple Start Event.

When to use and avoid

When to use

  • To start a process only after all of a set of events happened, shown explicitly as separate catch events.

  • When the diagram benefits from displaying each awaited trigger as its own event shape.

  • In documentation of complex instantiation contracts.

When NOT to use

  • When any single event should start the instance — regular event-based gateway (or Multiple Start).

  • In everyday models — it is exotic; the Parallel Multiple Start Event is usually more compact.

  • If your engine doesn't support instantiating gateways — many don't; check first.

Business example

Waiting for reply AND documents (conceptual)

Diagrama BPMN: Waiting for reply AND documents (conceptual)
Waiting for reply AND documents (conceptual)

Open this example in the HEFLO process editor and explore the diagram from the inside.

Open in the HEFLO editor →

Step by step

  1. The diagram shows the gateway followed by its awaited events — in the parallel variant, both the message and the timer condition must occur before work begins.
  2. Order of arrival doesn't matter; the engine collects them.
  3. Once the full set is in, the instance starts and proceeds.

The rendered shape here shows the standard event-based race for comparison; the parallel variant swaps the inner pentagon for a plus and changes semantics from OR to AND.

Differences

Parallel Event-Based Gateway vs Parallel Multiple Start

Same AND-instantiation semantics; different notation ergonomics. The start event version is compact (one symbol); the gateway version spreads each awaited event visibly. Most modelers pick the start event.

FAQ

Does it exist in intermediate (mid-flow) position?

The parallel variant is specified for process instantiation. Mid-flow AND-waiting is modeled with a parallel gateway plus catch events on each branch.

How are the collected events correlated?

By shared business keys, as with the Parallel Multiple Start — the engine must recognize they belong to the same future instance.

Related elements