In BPMN 2.0, what happens when two sequence flows enter a task directly with no gateway, and when must an explicit gateway be drawn?

## Uncontrolled flow BPMN 2.0 (OMG formal/13-12-09) allows an activity to be the target of **several** sequence flows without any gateway in front of it. The specification calls this **uncontrolled flow**: flow that proceeds without dependencies or conditions. Its semantics are stated exactly: - For **each token** arriving on **any** incoming sequence flow, the task is enabled **independently** of tokens on the other incoming flows. - The presence of several incoming sequence flows **behaves as an exclusive gateway**. - If the flow into the task must be controlled, **gateways other than exclusive** should be included explicitly before the task. The same applies to an intermediate event with several incoming flows: each arriving token enables the event separately, and a separate instance of it is created. The specification recommends a converging gateway in front of the event if the flow must be controlled. ## The implicit parallel split on the outgoing side The mirror rule applies when several sequence flows **leave** an activity. Without conditions, all of them receive a token when the activity completes, so the activity behaves as an implicit **parallel split**. (Conditional flows leaving an activity are a different subject, the sequence-flow rules.) | Pattern | Implicit behaviour | Equivalent explicit gateway | |---|---|---| | Several flows into an activity | each token enables it separately | exclusive merge | | Several unconditional flows out of an activity | every flow gets a token | parallel split | | Several flows into an intermediate event | each token enables the event separately | exclusive merge | ## When implicit flow is fine In the insurance-claim process, an exclusive split sends a claim either to "Fast-track settlement" or to "Full assessment". Both branches can flow directly into "Notify claimant": only one token ever arrives, so the implicit exclusive merge is exactly what is wanted. Many modellers still draw an explicit exclusive merge for readability, which does not change the behaviour. ## When it is a defect The same process starts "Obtain medical report" and "Obtain police report" together, either with a parallel gateway or by drawing two outgoing flows from "Open claim file". If both branches then flow **directly** into "Assess liability": 1. The first report's token arrives and enables "Assess liability", which runs with only one report. 2. The second report's token arrives and enables it **again**. 3. Everything after it, the decision letter and any payment, happens twice. The fix is an explicit **parallel gateway** as a join in front of "Assess liability". If the reports were requested by an inclusive split, the join is an explicit **inclusive** gateway. ## Rules of thumb - **Synchronising branches needs an explicit gateway.** An implicit merge never waits for the other branches; parallel, inclusive and complex gateways do. - **Alternatives may merge implicitly**; parallel branches may not. - A gateway must either split or merge: it needs more than one incoming or more than one outgoing flow. A best practice the specification mentions, which tools may enforce, is to let one gateway do only one of the two, so converge-then-diverge takes two gateways in sequence. - When a process has no start event, every flow node without an incoming flow starts its own parallel path, another form of implicit parallelism to watch for. ## Why the rule is defined this way Treating several incoming flows as an exclusive merge keeps simple diagrams simple: many merges join alternatives, and the notation lets the modeller draw them without an extra diamond. The cost is that concurrency is invisible at the point where it matters. A reader cannot tell from the task alone whether its incoming branches are alternatives or parallel; that depends on the splits upstream. This is why reviewers trace each incoming flow back to the split that created it before accepting an implicit merge. ## How to review a model for it - Find every activity and intermediate event with more than one incoming flow and ask whether its incoming branches can be active **at the same time**. If they can, a join is missing. - Find every activity with several outgoing unconditional flows and confirm the parallel split is intended, and closed by a matching join.