Collapsed subprocess navigation in the web-based bpmn modeler


Are there any plans / experiences / discussions regarding the use of collapsed subprocess in the modeler?

From a functional perspective, the story would be something like this : 'As a business analyst, I would like to used collapsed subprocess in the modeler, because currently, when my processes become very large, it requires a lot of scrolling, it cannot easily be printed, and the overview gets lost. I don’t want to use call activities because that creates several other technical challenges regarding process variable passing, and deployment versioning complexities. So rather, I would like to be able to split a big process in smaller parts, and have main/sub process navigation features in the modeler. The result should be one single BPMN process XML which I can deploy to the engine."

The alfresco activiti web modeler has some basic support for this - but seems too basic (seems to support only 1 level) and anyway it is/was not open-sourced.

So, are there any plans for this? Any advice / architectural remarks on how to do this? Any interest in this at all?


Hi Pieter,

Yes that’s something that would be needed in the Modeler indeed.
To implement it in the Modeler itself is not too hard, the difficult part is the generation of one BPMN XML file and the corresponding DI info. Calculating the DI for the whole diagram can be quite tricky. Any suggestions are welcome.

Best regards,


We have a similar requirement as I posted on the Activiti forum some time ago:

We are creating our own design tool, so I did not pursue it further. However, I did get support for a multidiagram parser:

which has been resolved using some manual merges. Refer to the converter class org.activiti.bpmn.converter.SubprocessXMLConverter. We are using a GoJS BPMN plugin, so we had to translate between the base Activiti model and their code, but I did some exploratory work on getting the Eclipse-based Designer tool to support multiple diagrams. I got stuck with the way the element ids were generated as they were scoped within the diagram and could not be easily applied between related diagrams.

I will attach some of the test bpmn files we have generated so far, but it should be easier to manage subprocesses in this manner if we can simply reuse the main process auto-layout functionality for subprocesses rather than attempt to scope them within the existing parent process.

We have moved to Flowable, so let me see if I can resurrect my old code. If someone has time to take a look, that would be great. For licensing and standardization purposes, we have to go with our company UI direction, but our developers really like using the standalone Eclipse tool.

Here are a couple of examples with DI data:

This first one is a basic nested subprocesses diagram with 3 levels which we generated using a migration utility from our existing proprietary format - so it reuses the coordinates from our old format:


This one is a basic example from one of our solutions - also migrated, but without BPMNDI. I imported it into our GoJS-based design tool and revised the layout before exporting it with the DI values:


Thanks Lori, what could work is if we would add separate BpmnDiagram elements for every sub process like you shared in the migrated BPMN example. Doing it like that would mean we don’t have to recalculate the DI information, but can actually include the DI info of every sub process as-is. We would only need to work on a solution for the readonly view of the process to make collapsed sub processes traversable there as well. Good insights I think that could help with building a good collapsed sub process solution.



Yes, if I recall, I had no issues moving from the initial configuration to separate diagrams because, as you mentioned, I could simply reuse the existing BPMN DI data. The only issue I had was moving from the separate diagrams to a single one and I tried to use the existing subprocess autolayout function to do so. In other words, I had added a feature Eclipse to select which layout was preferred and could almost round-trip, but hit a problem with id generation. I will keep looking for my old code and perhaps someone with more time can take it further.

Hi, thanks already for the feedback on this issue.
We’ll make an attempt to implement subprocess navigation, hopefully it works out.
So far, our intention is:

  • don’t try to recalculate diagrams in the XML; each collapsed subprocess should have its own bmpndiagram / plane (which , as I hopefully understood well, is what also the previous replies concluded)
  • in the angular part of the web modeler, add a tree component which shows the main process, and its collapsed subprocess elements, (and continue for deeper levels)
  • in that part of the angular app, selecting the main process or subprocess should trigger a switch of the oryx part (open the scope of the select main or subprocess for editing). But in the background, it’s still a huge JSON model for the editor.
    We don’t use the eclipse modeler ; so I have no clue at the moment how that will work out there.

Hi Tijs, Ismall,

Thanks for the feedback / insights on this topic.

Below are some screenshots to give everyone an idea what changes we are performing inside the web modeler.

The collapsed subprocess you see in the model is a fixed stencil / svg and currently can’t be stored in the bpmn20.xml (work in progress) yet. Our first goal is to have a nice an stable editor to create collapsed subprocesses before we tackle the translation from json -> bpmnmodel -> xml and visa versa.



Hi David,

Looks really promising! Looking forward to play with it!

Best regards,


Hi all,

The implementation is visible in the following fork: under branch collapsed-subprocess.

#Changes summary
In this branch the following high level changes are performed. Collapseable subprocess can now be drawn in the modeler and used in the activiti engine. Below are the summary points per component.

Editor / modeler

  • removed $rootScope.editor to an editorManager angular service.
  • replaced all field calls of $rootScope.editor to method calls on the editorManager.
  • added a process navigator panel to navigate between structural elements.
  • canvastracker now keeps track of multiple canvas configurations and is used to load and save the full model json.
  • All configuration to load and save editor configuration are now fetch trough angular $http request instead of prototype syncronous ajax calls.
  • The oryx component does not fetch any data anymore. The init logic has been altered to reflect the move to angular.


  • Added Collapseable Subprocess who extends Subprocess
  • performed changes to convert modeler json with collapsed subprocess to java and visa versa
  • performed changes to convert java to xml and visa versa
  • Added unit test with graphicinfo validation assertions.

#Discussion points

#Current bugs / UI annoyences

  • The properties should not been shown if the user clicks on the canvas when creating the process insided the collapsed subprocess. A collapsed subprocess should always be configured from the parent view.
  • When navigating between structural processes the undo history must be resetted as the commands executed to the modeler could lead to strange undo behavior.
  • When saving the model the svg saved is a respresentation of the current “layer” you are working on.
  • Eclipse plugin has not been updated.
  • Image generator has not been updated to support collapseable subprocesses.

Hi David,

Really nice work. Played with it for a while and it’s working really well.
The approach with having separate BPMNDiagram elements for a collapsed sub process is a good I think.
Great stuff!

Best regards,


Hi tijs,

Could you provide feedback on the following topics:

The indicator that a subprocess is collapsed:

  • Currently this is done in the xml by adding the attribute activiti:collapsed=true
  • This could also be stored in the drawing info node isExpanded=true.

The activiti:collapsed is not a supported attribute in the schema validation files.

Storage of the canvas info

The storage of resourceId-canvas as a BPMNShape seems to cause problems if you want to deploy the model trough the engine using the modeler explorer code. We could drop this info and the modeler/eclipse plugin could adjust the drawing canvas as they seem fit.

What are your preferences to save these data pointers?

Thanks in advance!


Hi David,

The isExpanded BPMNShape attribute is probably the best attribute to use, because it’s BPMN compliant.
Can you explain in a bit more detail what you mean with “resourceId-canvas as a BPMNShape seems to cause problems” ?



Hi tijs,

In the example xml you can see the following shape:

<bpmndi:BPMNShape bpmnElement="sid-C20D5023-C2B9-4102-AA17-7F16E49E47C1-canvas" id="BPMNShape_sid-C20D5023-C2B9-4102-AA17-7F16E49E47C1-canvas">
    <omgdc:Bounds height="1050.0" width="1200.0" x="0.0" y="0.0"></omgdc:Bounds>

This is not valid according to the schema validation as the bpmnElement sid-C20D5023-C2B9-4102-AA17-7F16E49E47C1-canvas does not match an existing element under the process node.

So im looking for an alternative to store this information or walk a different path of not storing the canvas info.

Best regards,


Hi David,

Thanks for the additional info, I understand the issue now.
We also don’t store the canvas info for the main process as well.
So I think we can leave it out for now. In the JSON it can still be stored if need, but it doesn’t need to be in the XML.
You could also add it to the Collapse sub process XML as an extension element, so the information is not lost, if needed.

Best regards,


Hi tijs,

Thanks for the feedback. I am currently changing the implementation to the following. (not yet visible on github atm)


The storage of the isExpanded = true instead of activiti:collapsed=true. An important notice here is that it might be a bit confusing from what “angle” you look to this. Here is my point of view :

A subprocess with isExpanded true equals to a collapseable subprocess in the modeler. The isExpanded points to the way the user draws the subprocess. If it is a normal subprocess the user draws the subprocess inside the process so nothing is expanded. When the user draws a subprocess in a context of a collapseable subprocess the subprocess is expanded before the user can start drawing / editing the subprocess.
On the code level using false as default for collapseable subprocesses could lead to strange behavior for existing subprocesses as the default for a boolean in java is false.

Canvas information

I will remove the storage of the canvas information. We don’t need it as we can always calculate the minimum size and take corresponding actions.
In this case the modeler will have to perform some additional actions when loading the collapseable subprocess. The BPMNDiagram representing the canvas info will be removed as a childshape of an collapseable subprocess leading to a simpeler json structure.

Best regards,


We have our own implementation and, based on the usage for our current workflow service, we decided to only support isExpanded=false and all subprocesses are in their own editor pane. In fact, we are hoping to reuse the autolayout functionality for the main process across our subprocesses, but I have not had time to re-evaluate it.

Hi David,

I understand the isExpanded attribute definition as follows:

  1. By default isExpanded is true for a sub process (also to be backwards compatible). So the default value of the isExpanded boolean is true and will only be set to false when there’s an isExpanded attribute with value false.

  2. When there’s a collapsed sub process, then the isExpanded attribute is set to value false.

I think this should work.

Best regards,


Ok, to sumarize then , to be sure: is this how the BPMN XML should be composed?
-The engine supports only one 'root' <process> tag (otherwise, you would be talking about the multi-swimmingpool model, which isn't supported).
- nested in this <process> tag of the xml: each collapsed subprocess should have one corresponding <subprocess> tag with isExpanded = true
- This root process (=main process) has one <bpmndi:BPMNDiagram> tag, containing exactly one <bpmdi:BPMNPlane> tag.
- For each collapsed subprocess, there should also be exactly one corresponding <bpmndi:BPMNDiagram> tag, containing exactly one <bpmdi:BPMNPlane> tag. The attribute bpmnElement of BPMNPlane should point to the specific <subprocess> 

So, to avoid any parsing problems, this means that the modeler will need the following 'integrity check' when opening an XML file:
 each <subprocess isExpanded=false> should have a matching <bpmdi:BPMNPlane> tag.

Yes, that is how we are managing it in our editor. So, a BPMNShape for the collapsed subprocess in the containing parent plane and a corresponding BPMNPlane for the subprocess contents. Here is a complex example of one of our migrated flows that includes nested subprocesses.