If you’re working with on a complex enough business process then at some point the process diagram will become bloated and unreadable. This means it’s time to make hierarchical decomposition - in simple words, split the process to subprocesses. The old rule of having 5 to 9 activities per level is fully applicable to BPMN.

Let’s consider the contract process with three phases:

1. Agree essential terms of the contract
2. Agree the contract text
3. Authorize the contract

Naive process diagrams like the following aren’t rare:

Fig.1 Naive diagram

I call it naive because it doesn’t provision early completion of the process e.g. because the agreement on the essential terms was not reached. As a rule, each subprocess should be followed by a gateway evaluating its results:

Fig.2 Subprocess results evaluated

A reasonable question is what the evaluation after the last subprocess is for - the process will end either way. The answer: because these are different completions - successful and non-successful. It’s nice to see it on a diagram and if the diagram is executable then we’d get the statistics of successful vs. non-successful ratio.

One should realize that even if an event on a BPMN diagram doesn’t lead to any explicit action, it is logged by a process engine: every process instance produces records that certain events have happened at certain times. So if we want to place milestones and control timings from the start to a milestone or from one milestone to another then we should just add intermediate none event:

Fig.3 With milestones

BTW, we just answered to the frequently answered question: “How milestones are modeled with BPMN?”. The answer: “By intermediate events like at Fig.3.

So far so good but if we look inside a subprocess then we’d likely find the same evaluation as in the outer process. E.g. the “Agree Contract Text” subprocess:

Fig.4 Double check

As we can see the evaluation of whether the text was successfully agreed is performed twice. People with programmer’s background don’t like things like this rightfully pointing out that it’s a duplication.

Now how can we get rid of the duplication? We can’t just draw two exits like at the next diagram. It’s a bad mistake: control flows cannot cross subprocess boundaries in BPMN.

Fig.5 Invalid diagram: control flow crosses subprocess boundary

The right way is to treat one of the exits as main/desirable and others as business exceptions. For the case in question:

Fig.6 Subprocess exit via escalation

If the contract text is not agreed then the subprocess initiates escalation event and the control is passed to the attached event.

Complete diagram with collapsed subprocesses:

Fig.7 Escalations and milestones

Be aware that escalations were introduced only in BPMN 2.0 so if you are confined by BPMN 1.x then use error events instead:

Fig.8 BPMN 1.x: errors instead of escalations

Milestones are optional here and may be omitted for compactness:

Fig.9 Compact version without milestones

Summary:

1. Use patterns at Fig.2 and 9 to model subprocess; it’s a matter of taste which one to use.
2. Diagrams at Fig.3 and 8 are modified with intermediate events that model milestones.
3. If the tool supports BPMN 2.0 then use escalations instead of errors in Fig.8 and 9 like shown at Fig.7.