BPMN Call Activity vs Subprocess: What’s the Difference?

BPMN has an element that looks very much like a subprocess, except drawn with a thick border. Perhaps you have used it yourself… probably incorrectly. Its name is call activity, and it is similar in several ways to a subprocess, but it is not the same. Both elements are important, but valuable for different reasons. This post will explain.

Call activity and subprocess share important characteristics. Both are simultaneously a single activity and an activity flow from start event to end event. And both may be rendered in the diagrams in two different ways: collapsed, denoted with a [+] marker at bottom center, or expanded, an enlarged rounded rectangle enclosing the flow. In BPMN 1.x, call activity and subprocess were actually variants of the same element. What we today know as a subprocess back then was called an embedded subprocess, and call activity was called a reusable subprocess. Of course, no one knew exactly what that meant. Some thought it had to with the shape – collapsed or expanded – but it had nothing to do with that. BPMN 2.0 resolved the distinction more clearly.

A subprocess is really just a graphical device. It allows a process fragment to be collapsed into a single activity to allow a higher level view of the end-to-end process. Rather than needing to create a high-level process model you can print on one page and a separate detailed model that stretches over six feet of wall space, and keeping those models in sync as the process definition evolves, subprocesses allow a single model of cross-functional end-to-end processes containing both high-level and detailed views. That model is not a single diagram but a hierarchy of diagrams, in which the contents of subprocesses are detailed in separate child-level diagrams. This presupposes use of the collapsed subprocess shape, with the child level drawn in a separate diagram, as opposed to the expanded shape, where parent and child levels are drawn in the same diagram.

In my work, I rarely if ever use the expanded subprocess shape. In Method and Style, my top-down methodology for non-executable models, you start with the collapsed subprocess in the parent-level diagram, then click the [+] marker to create a hyperlinked diagram where you add the child-level flow. Method and Style gives subprocesses additional importance by interpreting the labels of the child-level end events as the distinct end states of the subprocess, and requiring that any subprocess with multiple end states be followed by an XOR gateway, one gate per end state with matching labels. In this way, the end-to-end flow logic is evident from the printed diagrams even without defining process data.

While Method and Style simply would not work without subprocesses, the child-level flows enclosed by each subprocess have no independent meaning or definition. They are simply fragments of a larger process selected by the modeler to simplify visualization of the end-to-end process logic. This is fine for non-executable models, but it is far less valuable in executable BPMN. A subprocess is not executable. The unit of execution in BPMN is a process. So if you want to make some fragment of a larger process executable, you need to define that fragment as a top-level process and invoke it from the larger process using a call activity. The flow contained in a call activity is an independently-defined process. Where BPMN 1.x described call activity as a reusable subprocess, a better description would be an executable subprocess.

Call activities are as essential to Business Automation as subprocesses are to Method and Style . Executable models add to descriptive BPMN the elements of data flow – process variables (data objects) and their mapping to and from task inputs and outputs. In Business Automation, the shape labels so important in Method and Style effectively become annotations; the real logic is defined by the process data. Every task in executable BPMN defines a data mapping from process variables to the task inputs and from the task outputs to other process variables. The task inputs of a call activity are, by definition, the data inputs of the called process, and the task outputs of a call activity similarly are the data outputs of the called process. In the calling process, the call activity specifies a mapping from its process variables to and from the data inputs and outputs of the called process. The existence of such a mapping is indicated by data associations in the parent-level diagram. The data mappings themselves are defined in configuration of the call activity.

This mapping is what makes the called process reusable. Its data inputs and outputs are independent of the variables of any calling process, so long as there is a definable mapping. In contrast, the child level of a subprocess is not reusable, meaning defined once and used multiple times. It has no definition outside of the context of the larger process in which it is embedded. More to the point, a subprocess has no data inputs or data outputs. The individual tasks within the child level have them, but the subprocess as a whole does not. And this in fact is what makes subprocesses less useful in executable BPMN, because in the parent level diagram you cannot draw data flow to the boundary of a collapsed subprocess. Instead you need to draw the data flow in the child-level diagram only, losing the visual context of the flow from and back to the parent level. (You could fake it by using directional association connectors in the parent-level diagram – actually not a bad idea, and more consistent with Method and Style – but a real data association is not allowed by the metamodel.)

In Business Automation, a BPMN process can be compiled and deployed as a cloud REST service. As I have described numerous times in past posts, this requires just a single Cloud Publish mouse click on the Trisotech platform. And you could invoke that process from another BPMN process with a normal Service task. But when the calling process and the called process share a common platform, such as Trisotech, invocation with a call activity is much better. That’s because, while independently defined, the calling process and the called process are tightly coupled. The call does not have to travel across the internet to invoke a service generated by a specific version of the process. The call stays within the common platform and invokes the latest version of the called process, which does not even have to be compiled and deployed. That may seem like a small thing, but in practice it makes development much easier.

While it is possible to create executable models top-down as in Method and Style, more often I will define the called processes first as independent models and then assemble them in the calling process using call activities. In the Trisotech Workflow Modeler, to bind a call activity shape to the called process, you can either drag the called process onto the diagram from the model repository (called Digital Enterprise Graph) or click on the Reuse button on the menu, which lets you pick from processes in the model repository. The call activity shape then displays a lock icon, indicating it is bound to the called process, inheriting its defined datatypes and synchronized to any changes in its internal logic.

Another important benefit of call activities in Business Automation is testing, which often takes as much effort as the design itself. Unlike DMN, which you can test in bits and pieces in the modeling environment, testing BPMN requires compilation and deployment, possible only at the process level. Breaking a complex process into small executable fragments makes the testing much more manageable, and the larger process can then assemble those fragments – which are now also reusable in other scenarios – using call activities.

The bottom line is that call activities play as vital a role in executable BPMN as subprocesses do in non-executable BPMN. Call activities are useful in non-executable BPMN only in the rare case where a subprocess is used multiple times in the same process or, possibly, where an organization has standardized the names of subprocesses for reuse across the enterprise. And while subprocesses are important in non-executable BPMN – Method and Style, in particular – they are most often better replaced with call activities in executable models.