BPMN Terms Explained


This series of articles is dedicated to the explanation of some of the most common Business Process Model and Notation (BPMN) terms. This article will explain these terms as defined in the BPMN 2.0 specification:

  • BPMN Fork
  • BPMN Join
  • BPMN Branch
  • BPMN Merge 

All terms relate to the point in a process diagram where the number of incoming sequence flows differs from the number of outgoing ones. To represent Fork, Join, Branch, and Merge in a business process diagram, three types of BPMN elements are used: Activities, Gateways, and Sequence Flows.

Process Fork

BPMN uses the term ‘fork’ to refer to the dividing of a path into two or more parallel paths. In other words, a fork indicates a point in the process where activities can be performed concurrently, rather than sequentially. A process fork can be implemented by using (Figure 1):

  • Multiple outgoing sequence flows. This represents an ‘uncontrolled’ flow, which stands for a “flow that proceeds without dependencies or conditional expressions”.
  • A parallel gateway. This represents a ‘controlled’ flow, which stands for a “flow that proceeds from one flow object to another via a sequence flow link, but is subject to either conditions or dependencies from other flows as defined by a gateway”.

Figure 1: Uncontrolled Fork (left) and controlled Fork (right)

Process Join

BPMN uses the term ‘join’ to refer to the combining of two or more parallel paths into one path (also known as an AND-Join or Synchronization). A parallel gateway is used to visualize the joining of multiple sequence flows (Figure 2).


Figure 2: Process Join

Process joins are commonly used in combination with a ‘controlled fork’ (using AND-AND gateways).

Process Branch

Branches or decisions are represented with gateways, which enable the flow of control to take one or more alternative paths. Several gateways, as well as conditional sequence flows, can be used for branches. In the case that only one alternative path can be chosen, an exclusive gateway should be used (Figure 3). The alternative paths can be defied by:

  • A conditional expression contained within the outgoing sequence flows. In this case, a (data-based) exclusive gateway should be used.
  • An event that occurs at that point in the process. In this case, an event-based exclusive gateway should be used. Besides events, tasks of the type ‘receive’ can also be used.

Figure 3: Exclusive Branches – data-based (left) and event-based (right)

In case that several alternative paths can be chosen, an inclusive branch should be used. In the case of an inclusive branch, each alternative path is independent, so all combinations of the paths may be taken (from zero to all). To ensure that a process does not get stuck at the gateway, it should be designed so that at least one path can be taken. A default condition could be used to ensure that at least one alternative path is taken. Inclusive branches can be modeled in two ways (Figure 4):

  • By using an inclusive gateway
  • By using a collection of conditional Sequence Flows, marked with mini-diamonds.

Figure 4: Inclusive branches – gateway-based (left) and conditional sequence flow-based (right)

Process Merge

BPMN uses the term ‘merge’ to refer to a point in the process where two or more alternative sequence flow paths are combined into one sequence flow path. BPMN uses multiple incoming sequence flows for an activity or an exclusive gateway to perform a merge (Figure 5). If all the incoming flows are alternative, then an uncontrolled merge provides the same behavior as the controlled one.


Figure 5: Uncontrolled Merge (left) and controlled Merge (right)


The terms Fork, Join, Branch, and Merge, as defined in the BPMN 2.0 specification, were explained. All terms relate to the point in a process diagram, where the number of incoming sequence flows differs to the number of outgoing ones.

BPMN 2.0 Gateways - Interactive guide

Are you interested in writing for Good e-Learning? We are currently accepting guest contributions and content exchanges in areas like ITSM, DevOps, and Cyber Resilience. Visit our Write for Us page to find out more, or contact a member of our team today!

Gregor received his PhD in 2008 in the fields of software engineering and information systems and has nearly a decade of experience in BPMN, starting to investigate and actively use BPMN since its introduction in 2004. In addition, he has participated in the development of one of the first BPMN modeling utilities - a package of plugins for Visio, which were introduced early in 2005 and is the main author of the first BPMN poster (bpmn.itposter.net), which has been translated into several languages and already exceeded 50.000 downloads.