A BPMN 2.0 task 'Review order' has a conditional flow to 'Manager approval' and a plain flow to 'Send order'; why do large orders go out unapproved?

seniorshould knowfreq 28%

answer

an activity's outgoing flows all fire
unconditional means always
conditions from a task act inclusively
slash marker, not a bare line

basics

~20 s

In BPMN 2.0 every unconditional flow leaving a task gets a token on completion, so 'Send order' always runs alongside approval. Marking it the default flow (slash marker) makes it fire only when no condition holds.

solid answer

~50 s

In BPMN 2.0.2 an activity with several outgoing sequence flows puts a token on all of them when it completes; flows with conditions act like an inclusive split, and a mix of conditional and unconditional flows is a parallel plus inclusive split (execution semantics, clause 13). The plain flow to Send order is unconditional, so it fires on every completion; for a large order the conditional flow to Manager approval fires as well, and the order is sent in parallel with approval. The fix is to make the plain flow the default flow: draw it with the slash marker and reference it from the task's default attribute. A default flow is taken only if every other outgoing flow's condition is false, and any condition placed on it is ignored. If the conditions themselves can both be true, the task still splits inclusively, so for either-or routing they must be mutually exclusive.

In BPMN 2.0.2 an activity with several outgoing sequence flows puts a token on **all** of them when it completes; flows with conditions act like an **inclusive** split, and a mix of conditional and unconditional flows is a parallel plus inclusive split (execution semantics, clause 13). The plain flow to `Send order` is unconditional, so it fires on every completion; for a large order the conditional flow to `Manager approval` fires **as well**, and the order is sent in parallel with approval. The fix is to make the plain flow the **default flow**: draw it with the slash marker and reference it from the task's `default` attribute. A default flow is taken only if every other outgoing flow's condition is false, and any condition placed on it is ignored. If the conditions themselves can both be true, the task still splits inclusively, so for either-or routing they must be mutually exclusive.

code

xml · 7 lines

xml

<task id="ReviewOrder" name="Review order" default="ToSendOrder"/>

<sequenceFlow id="ToApproval" sourceRef="ReviewOrder" targetRef="ManagerApproval">
  <conditionExpression>Order amount is above the approval limit</conditionExpression>
</sequenceFlow>

<sequenceFlow id="ToSendOrder" sourceRef="ReviewOrder" targetRef="SendOrder"/>

go deeper

for a junior

Recognise the two markers: a mini-diamond means a conditional flow, a slash means the default flow.

for a middle

Explain that all unconditional outgoing flows from a task fire, and that conditional ones act as an inclusive split.

for a senior

Diagnose unintended parallel paths by counting tokens per case, then fix with a default flow and mutually exclusive conditions.

for a principal

Set modelling conventions on when conditions may sit on activity flows versus an explicit decision, weighing compactness against misreading risk.

The symptom

In the buyer's process, Review order has two outgoing sequence flows:

a conditional flow, drawn with a mini-diamond at its start, labelled "amount above approval limit", to Manager approval;
a plain flow, no marker, to Send order.

The modeller meant "approve large orders, send the rest". In practice large orders are sent before approval completes, and sometimes approval rejects an order that has already gone to the supplier.

What BPMN 2.0.2 actually says about outgoing flows from an activity

The execution semantics chapter is explicit:

If an activity has multiple outgoing sequence flows, all of them receive a token when the activity completes: a parallel split.
Multiple outgoing sequence flows with conditions behave as an inclusive split: every flow whose condition is true gets a token.
A mix of flows with and without conditions is a combination of a parallel and an inclusive split (Figure 13.1).

So the plain flow is not "the other branch". It is unconditional and fires every time. For a large order, both flows fire: one token goes to approval and one to sending, and the two paths run independently.

The fix: a default flow

The standard provides exactly the construct the modeller wanted:

A sequence flow whose source is an activity or an exclusive, inclusive or complex gateway can be defined as the default. The source's default attribute references it.
It is drawn with a slash marker at the beginning of the connector.
It is taken only if all the other outgoing sequence flows are not valid, that is, their condition expressions are false.
The default flow should not have a conditionExpression; if one is present it SHALL be ignored.

With the plain flow marked as default, a large order gets a token only on the approval path; a small order gets a token only on the default path to Send order.

Notation rules a reviewer checks at the same time

Rule (BPMN 2.0.2, clause 8.4.13)	What it prevents
A conditional flow leaving an activity MUST have the mini-diamond marker	reading a gated flow as unconditional
A conditional flow from an activity requires at least one other outgoing flow	a task whose only exit can be closed
Conditional flows leaving a gateway MUST NOT have the mini-diamond	double-marking gateway branches
A conditional flow's source gateway MUST NOT be parallel or event-based	conditions that would be meaningless
A default flow MUST have the slash marker	confusing a default with an ordinary flow

Remaining traps after the fix

Overlapping conditions. If there are two conditional flows, say "amount above limit" and "new supplier", an order satisfying both gets two tokens, because conditions from an activity split inclusively. If the intent is either-or, the conditions must be written to be mutually exclusive, or the choice moved onto an explicit exclusive gateway.
No fallback. If every outgoing flow is conditional and none is default, the specification offers no other fallback; the case where all conditions are false has no modelled continuation. A default flow closes that gap.
Reading the diagram only. A default flow is visible only by its slash marker; in the XML it is the activity's default attribute. Reviewing either one alone can miss a mismatch introduced by hand edits.

Counting tokens per case

A quick way to test any activity with several outgoing flows is to list the cases and count tokens:

Case	Before the fix	After the fix
Small order	1 token, to `Send order`	1 token, to `Send order` (default)
Large order	2 tokens, to approval and to `Send order`	1 token, to `Manager approval`

Any case that produces more tokens than the modeller intended is an unintended parallel path.

How to explain it in an interview

Name the rule (all unconditional outgoing flows from an activity fire), show the token count for a large order (two), then give the standard's fix (default flow, slash marker, default attribute) and the residual risk (overlapping conditions still split inclusively). That sequence shows you read the diagram as the specification defines it, not as the labels suggest.

## The symptom In the buyer's process, `Review order` has two outgoing sequence flows: - a **conditional** flow, drawn with a mini-diamond at its start, labelled "amount above approval limit", to `Manager approval`; - a **plain** flow, no marker, to `Send order`. The modeller meant "approve large orders, send the rest". In practice large orders are sent before approval completes, and sometimes approval rejects an order that has already gone to the supplier. ## What BPMN 2.0.2 actually says about outgoing flows from an activity The execution semantics chapter is explicit: 1. If an activity has multiple outgoing sequence flows, **all of them receive a token** when the activity completes: a **parallel split**. 2. Multiple outgoing sequence flows **with conditions** behave as an **inclusive split**: every flow whose condition is true gets a token. 3. A mix of flows with and without conditions is a combination of a parallel and an inclusive split (Figure 13.1). So the plain flow is not "the other branch". It is unconditional and fires every time. For a large order, both flows fire: one token goes to approval and one to sending, and the two paths run independently. ## The fix: a default flow The standard provides exactly the construct the modeller wanted: - A sequence flow whose source is an **activity** or an exclusive, inclusive or complex gateway can be defined as the **default**. The source's `default` attribute references it. - It is drawn with a **slash marker** at the beginning of the connector. - It is taken **only if all the other outgoing sequence flows are not valid**, that is, their condition expressions are false. - The default flow should not have a `conditionExpression`; if one is present it SHALL be ignored. With the plain flow marked as default, a large order gets a token only on the approval path; a small order gets a token only on the default path to `Send order`. ## Notation rules a reviewer checks at the same time | Rule (BPMN 2.0.2, clause 8.4.13) | What it prevents | |---|---| | A conditional flow leaving an **activity** MUST have the mini-diamond marker | reading a gated flow as unconditional | | A conditional flow from an activity requires **at least one other** outgoing flow | a task whose only exit can be closed | | Conditional flows leaving a **gateway** MUST NOT have the mini-diamond | double-marking gateway branches | | A conditional flow's source gateway MUST NOT be **parallel** or **event-based** | conditions that would be meaningless | | A default flow MUST have the **slash** marker | confusing a default with an ordinary flow | ## Remaining traps after the fix - **Overlapping conditions.** If there are two conditional flows, say "amount above limit" and "new supplier", an order satisfying both gets two tokens, because conditions from an activity split inclusively. If the intent is either-or, the conditions must be written to be mutually exclusive, or the choice moved onto an explicit exclusive gateway. - **No fallback.** If every outgoing flow is conditional and none is default, the specification offers no other fallback; the case where all conditions are false has no modelled continuation. A default flow closes that gap. - **Reading the diagram only.** A default flow is visible only by its slash marker; in the XML it is the activity's `default` attribute. Reviewing either one alone can miss a mismatch introduced by hand edits. ## Counting tokens per case A quick way to test any activity with several outgoing flows is to list the cases and count tokens: | Case | Before the fix | After the fix | |---|---|---| | Small order | 1 token, to `Send order` | 1 token, to `Send order` (default) | | Large order | 2 tokens, to approval and to `Send order` | 1 token, to `Manager approval` | Any case that produces more tokens than the modeller intended is an unintended parallel path. ## How to explain it in an interview Name the rule (all unconditional outgoing flows from an activity fire), show the token count for a large order (two), then give the standard's fix (default flow, slash marker, `default` attribute) and the residual risk (overlapping conditions still split inclusively). That sequence shows you read the diagram as the specification defines it, not as the labels suggest.

In BPMN 2.0, what happens if the default flow also carries a conditionExpression?
The specification says a default sequence flow should not have a conditionExpression and that any such expression SHALL be ignored. The flow is still taken exactly when all other outgoing conditions are false, so the stray condition only misleads readers.
In BPMN 2.0, may a default flow leave a parallel gateway?
No. Only a sequence flow whose source is an exclusive, inclusive or complex gateway, or an activity, can be defined as default. A parallel gateway sends a token on every outgoing flow, so a default has no meaning there.
In BPMN 2.0, why is the mini-diamond missing on conditional flows leaving a gateway?
The standard says conditional outgoing flows from a gateway MUST NOT be drawn with the mini-diamond; the gateway symbol already signals the decision. The diamond appears only when the condition sits on a flow leaving an activity directly.

It is like a mail room rule that says 'copy every letter to Dispatch, and also to the Manager if it is over the limit': the Manager sees large letters, but Dispatch has already sent them. A default rule reads 'send to Dispatch only if no other rule matched'.

saying these in an interview costs you the question

Assuming a plain flow beside a conditional flow is the else branch
Believing only one outgoing flow from a task can ever fire
Putting a condition on the default flow and expecting it to apply
Drawing conditional flows from a task without the mini-diamond marker
Assuming mutually overlapping conditions from a task pick just one path

A BPMN 2.0 task 'Review order' has a conditional flow to 'Manager approval' and a plain flow to 'Send order'; why do large orders go out unapproved?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The symptom

What BPMN 2.0.2 actually says about outgoing flows from an activity

The fix: a default flow

Notation rules a reviewer checks at the same time

Remaining traps after the fix

Counting tokens per case

How to explain it in an interview

▾common follow-ups3 questions

▾analogy~20 s

▾red flags5 flags

The symptom

What BPMN 2.0.2 actually says about outgoing flows from an activity

The fix: a default flow

Notation rules a reviewer checks at the same time

Remaining traps after the fix

Counting tokens per case

How to explain it in an interview

answer

go deeper