Sub-Processes

Run Another Process Model from a Call Activity

Sub-Processes

A sub-process lets a step of your process run another process model.
The main process waits at this step. As soon as the sub-process is finished, the main process continues. From the point of view of the main process, the sub-process behaves like one single task.

Use sub-processes to:

Reuse a process in several other processes, for example an approval or an onboarding.
Keep large models readable: Move a part of the process into its own model.
Let different teams own different parts: Each model can be maintained and published on its own.

Sub-processes are available from Flower 3.5.0, in Jira Cloud and in Jira Data Center.

Call Activity or Embedded Sub-Process?

BPMN has two ways to draw a sub-process. Flower treats them differently:

BPMN element	What it does in Flower
Call activity	Runs another process model. Use it whenever you want to start a sub-process.
Embedded sub-process	Only a graphical device to group steps in a model. Flower does not start anything for it.

Technically, any task that is linked to a model through the Jira work type mapping starts that model. Flower recommends and documents the call activity for this purpose, because it shows in the diagram that another process is called.

How It Works

A process instance reaches a call activity.
Flower creates a work item for it, like for any other task. Because the work type of this work item is mapped to a model, Flower turns the work item into a process instance of this model, the sub-process instance.
The sub-process runs. Its tasks are work items like in every other process.
When the sub-process instance is resolved, the main process continues after the call activity.

The work item of the call activity and the sub-process instance are the same Jira work item. So you see exactly one work item at this step, and its status tells you whether the sub-process is still running. The description of the work item says Flower Subprocess and names the parent process and the parent process instance. It is shown in a purple panel, tasks are blue, models and process instances green.

Set Up a Sub-Process

Publish the model that you want to call. Only published models can be started.
Map a work type to this model. Open the Flower Settings, go to the Jira Work Type Mapping tab, and select a space, a work type, and the model. See Setup Flower.
Model a call activity in the main model. Select the call activity, open the Jira section in the properties panel, and choose its space and work type. The lists only contain the values of the Jira work type mapping, and a link opens the Jira Work Type Mapping tab of the Flower Settings to change the mapping. A call activity needs its own space and work type: unlike for tasks, they are not inherited from the swimlane or the model.

💡

The Flower Modeler checks this when you validate the model: a call activity without space and work type, or with a combination that is not in the Jira work type mapping, is an error. A model that calls itself, directly or through other models, is an error too.

⚠️

A work type that is mapped to a model starts this model every time a work item of this type is created in this space, also for normal tasks. Use a mapped work type for call activities only. The validation of the Flower Modeler warns you if an ordinary task uses a mapped work type.

Descriptions and Placeholders

In the description of the work items of a sub-process (the documentation of an activity), the placeholder {{flower.parent}} is the key of the parent process instance, so you can refer to the work item of the main process. See User Tasks. The default description of a work item in a sub-process says that it runs as a sub-process of this parent.

Pass Data to a Sub-Process

Flower does not pass parameters to a sub-process. The sub-process is a process instance with its own data: the fields of its work item.

Fields of the call activity’s work item are the data of the sub-process instance. If the work type has a form, the form is part of the sub-process instance.
In the expressions of a gateway in the sub-process, pi is the sub-process instance, and par is the calling (parent) process instance. Use par to read data of the main process, for example ${par.fields.summary == 'New Request'}. See Decision Handling in Gateways.
In the main process, cur after the call activity is the work item of the sub-process instance. You can check its status and resolution, for example ${cur.fields.resolution.name == 'Done'}.

Forms and Mandatory Fields

Flower creates the work item of a call activity automatically, without a user filling in a screen. So the work type of a call activity must not have mandatory fields, otherwise Jira refuses to create the work item. Flower then writes an error comment at the calling process instance, see If a Sub-Process Cannot Be Started.

This applies to sub-processes started from a process. If a user starts the process directly, mandatory fields are fine and even wanted: Create the work item with the Jira Create button, or submit a form (also a Jira Service Management request), as described in Forms.

Versions

A sub-process starts with the version of the model that is published when the call activity is reached. If you publish a new version later, running sub-processes keep the version they started with. The next call starts the new version.

Ending a Sub-Process

Regular end: When the sub-process reaches its end event, Flower resolves its work item, and the main process continues.
Terminate end event in the sub-process: Ends only this sub-process. The main process continues as usual.
Terminate end event in the main process: Ends the main process and every running sub-process with all its open work items, also nested sub-processes. See BPMN End Events.
Resolution: When Flower resolves the sub-process, it also sets the Jira resolution (Done, or Won’t Do for a terminated process) if the workflow does not. For this the field Resolution must be on the transition screen or the edit screen of the work type, or set by a post function of the workflow. If it is on none of them, Flower still resolves the work item, writes a warning comment at the process instance and continues the main process on the status change into the done category. Without a resolution, JQL (resolution is EMPTY), the timer job and reports treat the work item as open.
Resolving the work item manually: If you resolve the work item of a sub-process by hand, the main process continues. Open work items inside the sub-process stay open. Close them yourself or let the sub-process finish first.

If the Work Type Is Not Mapped

If the space and work type of the call activity are not part of the Jira work type mapping when Flower creates its work item (for example the mapping was never saved, or an entry is gone), no sub-process can start. Flower creates an ordinary task and writes a warning comment at the calling process instance: The call activity ”…” does not start a sub process. The main process waits until you resolve this task. Add the entry on the Jira Work Type Mapping tab, or give the call activity a mapped work type. The validation of the Flower Modeler reports the same problem as an error before you publish. See Error and Warning Comments from Flower.

If a Sub-Process Cannot Be Started

If Flower cannot start the sub-process, for example because the model is not published any more or Jira cannot create the work item, it writes an error comment at the calling process instance. The call activity keeps its work item, and the main process keeps waiting.

Timers

A timer boundary event on a call activity sets the Jira due date of its work item like on any other task. Triggering the timer for call activities is planned for a later release.

Loops

A loop that leads back to a call activity is not supported. Flower does not reopen the sub-process and writes an error comment at the process instance instead. Start the sub-process again with a new process instance, or model the repetition inside the sub-process.

Nested Sub-Processes

A sub-process can call further sub-processes. A model must not call itself, neither directly nor through other models. This would start new process instances without end. The validation of the Flower Modeler reports such a cycle as an error.

Find Sub-Processes with JQL

A sub-process instance is a process instance that belongs to a node of the main process:

Goal	JQL
All sub-processes of a process instance	`flowerType = "Process Instance" AND flowerInstance = YOUR-INSTANCE-KEY`
The sub-process at one call activity	`flowerType = "Process Instance" AND flowerInstance = YOUR-INSTANCE-KEY AND flowerNode = YOUR-ACTIVITY-ID`
All running sub-processes	`flowerType = "Process Instance" AND flowerNode IS NOT EMPTY AND resolution is EMPTY`

The sub-process instance counts as a process instance of the called model. In the model report of the calling model, it also appears as an open work item at its call activity. More queries are in Search Flower Data with JQL.

What’s Next?

Setup Flower: Configure the Jira work type mapping.
User Tasks: Space and work type of an activity.
Decision Handling in Gateways: Use par in expressions.
BPMN End Events: What a terminate end event does to sub-processes.