In BPMN 2.0, how does a standard loop activity differ from a sequential or parallel multi-instance activity, and what does completionCondition do?
answer
- curled arrow versus three bars
- condition per iteration versus count up front
- bars vertical or horizontal
- stop early, cancel the rest
basics
~20 sIn BPMN 2.0 a standard loop repeats one activity while a condition holds; a multi-instance activity creates a count fixed up front, run in sequence or in parallel. Its completionCondition, checked as each instance completes, cancels the rest when true.
solid answer
~40 sA **standard loop** (curled-arrow marker) repeats an activity **one iteration at a time** while its `loopCondition` is true; `testBefore` chooses a pre- or post-tested loop (post-tested by default) and `loopMaximum` caps iterations. A **multi-instance** activity (three bars) creates **several instances** whose number is **evaluated once**, from `loopCardinality` or from the size of a collection in `loopDataInputRef`. With `isSequential="false"` (the default, vertical bars) they run in parallel; with `true` (horizontal bars) one after another. Its `completionCondition` is evaluated every time an instance completes; when true, the remaining instances are cancelled and the activity completes. For a loan's four-eyes sign-off, "Approve loan" is a parallel multi-instance user task over the approver list, with a completion condition such as "two approvals received"; "Request missing documents" is a standard loop.
go deeper
Recall the markers: curled arrow for a loop, three bars for multi-instance, vertical for parallel and horizontal for sequential.
Explain that a loop decides iteration by iteration while multi-instance fixes its count once, and how completionCondition cancels the remaining instances.
Model n-of-m approvals with a parallel multi-instance and a completion condition, and check what happens to cancelled approvers' work items.
Weigh parallel sign-off against sequential escalation chains with the business, balancing cycle time, approver load and audit expectations.
## Two ways to repeat work BPMN 2.0 (OMG formal/13-12-09) lets any task or sub-process repeat, through its `loopCharacteristics`. There are two concrete kinds, and an activity carries at most one of them, so loop and multi-instance markers never appear together: | | Standard loop | Multi-instance | |---|---|---| | Marker | small line with an arrowhead curling back on itself | three parallel bars: vertical if parallel, horizontal if sequential | | Element | `standardLoopCharacteristics` | `multiInstanceLoopCharacteristics` | | How many times | decided iteration by iteration by `loopCondition` | decided **once**, before the first instance | | Order | always one after another | sequential or parallel (`isSequential`) | | Early stop | the condition turning false, or `loopMaximum` | `completionCondition` becoming true | | Typical fit | "keep asking until the file is complete" | "do this once per item or per person" | ## Standard loop A standard loop behaves like a `while` or `do ... while` loop around the activity: - `loopCondition` is a boolean expression; the activity loops **as long as it is true**. - `testBefore` (default **false**) decides whether the condition is checked before each iteration (pre-tested) or after it (post-tested). Post-tested means the activity runs at least once. - `loopMaximum` caps the number of iterations; if it is not set, the loop is unbounded. - The run-time attribute `loopCounter` counts iterations. In the loan-approval process, "Request missing documents" is a natural standard loop: send the request, check what came back, repeat while documents are still missing, with a cap of, say, three rounds before the case goes to an officer. ## Multi-instance A multi-instance activity is a wrapper that spawns inner instances of the activity: 1. The **number** comes either from `loopCardinality`, an integer expression, or from `loopDataInputRef`, a collection with one instance per item. One of the two must be given, and the number is evaluated **once**. 2. `isSequential` (default **false**) decides whether the instances run **in parallel** or **one after another**; a sequential multi-instance never has more than one active instance. 3. Each inner instance gets its item through `inputDataItem`, and results can be collected through `outputDataItem` into `loopDataOutputRef`. 4. The outer instance exposes `numberOfInstances`, `numberOfActiveInstances`, `numberOfCompletedInstances` and `numberOfTerminatedInstances`; the last three always sum to the first. ## completionCondition `completionCondition` is a boolean expression that the specification says is **evaluated every time an instance completes**. When it is true, **the remaining instances are cancelled**, a token is produced on the outgoing sequence flow, and the multi-instance activity completes. Without it, the activity completes only when all instances have finished. For the loan's **four-eyes sign-off**, suppose three approvers are listed and any two approvals suffice: - "Approve loan" is a **parallel multi-instance user task** whose `loopDataInputRef` is the approver list, so three instances are created at once, one per approver. - The completion condition is true once the number of approvals collected reaches two. When the second approval completes, the third approver's instance is cancelled and the process moves on. - If a single rejection must end the sign-off, the condition also checks for a recorded rejection, so the first rejection cancels the other instances. ## Pitfalls - Using a **standard loop** for "once per approver": a loop has no per-item instances and never runs in parallel. - Expecting a multi-instance activity to **pick up items added later**: the number of instances was fixed when it started. - Forgetting the completion condition in an "n of m" rule, which makes every approver act even after the decision is already made. - Confusing the bar orientation: **vertical** bars mean parallel, **horizontal** bars mean sequential. - Leaving `loopCondition` or `loopCardinality` as prose in an executable model: the specification allows it to be under-specified, but then the loop cannot be formally executed.
- In BPMN 2.0, what happens to the instances still running when a multi-instance activity's completionCondition becomes true?They are cancelled. The specification says that when the condition evaluates to true the remaining instances are cancelled, a token is produced for the outgoing sequence flow, and the activity completes. The run-time counts then show them as terminated instances.
- In BPMN 2.0, how is the number of multi-instance instances determined?Either by `loopCardinality`, an expression that must evaluate to an integer, or by `loopDataInputRef`, a collection whose item count gives the number of instances. One of the two is required, and the number is evaluated once, before any instance starts.
A standard loop is asking "any more questions?" after each answer; a parallel multi-instance is handing the same form to three reviewers at once and collecting it back when enough have signed.
saying these in an interview costs you the question
- A multi-instance activity re-checks its instance count after every instance.
- A standard loop can run its iterations in parallel.
- Vertical multi-instance bars mean the instances run in sequence.
- completionCondition lets the other instances finish before completing.
- A standard loop always checks its condition before the first iteration.