BPMN allows model decomposition, encapsulation and detail hiding through the use of Sub Processes. These can be defined in a diagram, allowing the details of a process to be hidden from the top level process.
BPMN 2.0 has two methods for creating sub processes:
- BPMN Sub Processes, which allow you to create a sub process as part of your process diagram. Sub processes can be nested to contain other sub processes. All sub processes must be contained in the same diagram as their parent Process, and
- BPMN Call Activities, where one diagram is able to call a process or part of a process definied in a different diagram. This facilitates process decomposition and re-use of common processes / sub-processes by multiple diagrams.
Flows for APEX now allows you to create both sub processes within your process diagram, and callActivities to call other process diagrams. Sub processes can contain other sub processes, and so a deeply nested hierarchy of processes and sub processes can be built.
This page documents sub Processes. Call Activities are documented on this page.
Sub processes are embedded sub processes, and are contained within the same process diagram as their calling process. Global sub processes, which can be called from a different diagram, are supported using [Call activities]((https://flowsforapex.org/development/callActivities/) from v22.2 onwards.
Creating Sub Processes
Sub Processes are created using the modeler, as usual.
Boundary Events on Sub Processes
Sub Processes can have Timer, Error ad Escalation Boundary Events added to them. See [Boundary Events]((https://flowsforapex.org/development/boundary-events/)
Terminate End Events in Sub Processes
A Sub Process can contain a Terminate End Event. If a Terminate End Event is reached, all processing in the sub process, along with any processing in any nested child sub processes running inside it, are terminated. Control passes to the next event in the normal exit path from the sub process in its immediate parent process.
Rules for Sub Processes
1. Sub Processes must have a single Start Event.
A Sub Process must start with a single Start Event, which should be a simple Start Event (i.e., without any associated Timer, etc. event).
2. End Events
A sub process must have at least one End Event. If more than 1 end events are specified, the sub Process waits for all active subflows to complete before returning to its parent process. This acts like an implicit parallel merging gateway. (A Sub Process may also have additional non-standard end events, such as error end events, etc.).
3. Sub Processes are Embedded Sub Processes and Operate in a Single Lane.
As is correct for an embedded BPMN sub process, a sub process must operate in a single lane.
4. Event Sub Processes are not yet supported.
5. Sub Processes can be nested.
SubProcesses can be nested to arbitrary depth.
5. Sub Processes and Subflows.
When a subflow reaches a Sub Process object, the subflow gets a status of ‘In Subprocess’.
Processing in the SubProcess starts on a new subflow, which is running at the subprocess level.
Subflows inside a sub process can themselves split at parallel or inclusive gateways, creating new subflows running at the sub process level. They can also start a new child sub process – in which case the new parent sub process gets status ‘In Subprocess’, and its new child starts new subflows at the new sub process level.
For a sub process to complete normally, all subflows running at the subprocess level must complete by reaching an end event. When the last running subflow in a process level completes normally, the subprocess has completed, and processing continues on its parent subflow.
If a subflow triggers a non-interrupting boundary event, it will cause a new subflow to start on its parent’s process level.
If a subflow triggers an interrupting boundary event, for example an error event or an interrupting timer or interrupting escalation, all processing inside the subprocess is stopped, and the subprocess’ parent subflow continues on the path forward from the boundary event, if defined.