Maestro user guide

Last updated Nov 17, 2025

Subprocesses and modularity

Subprocesses support model clarity by grouping related activities into a single reusable structure. They help reduce diagram complexity, isolate business logic, and encourage reuse.

In BPMN, a subprocess can be modeled either inline or via a reusable call activity. In Maestro:

Only call activities are supported.
The subprocess must be modeled as a separate diagram.
The calling process passes input and receives output via defined parameters.

Why use call activities?

A call activity references a subprocess defined elsewhere in the project or environment. It behaves like a reusable function. call activities improve process modeling by:

Reducing duplication across diagrams
Isolating reusable logic (e.g., approvals, validations, dispatching)
Keeping the main diagram concise
Supporting consistent behavior across process variants.

How to model subprocesses

To create a subprocess in Maestro:

Model the subprocess as its own standalone diagram.
In the parent diagram, insert a call activity.
Link the call activity to the subprocess.
Configure input and output variables to exchange data.

Modeling examples

Use case: An onboarding workflow uses the same Collect Documents subprocess in both employee and vendor onboarding processes. Instead of duplicating steps, a call activity is added in each parent process referencing the same subprocess.

Use case: This subprocess example shows a conditional file download and upload workflow in Maestro. The process begins with a message start event and branches using an exclusive gateway. Depending on the condition, it either downloads an email attachment or a file from a record field. Both paths converge into an Upload File task, followed by a SubProcess element named Sub-Process1. This subprocess encapsulates additional steps related to post-upload actions before completing the workflow at the end event.

Modeling guidelines

Give subprocesses meaningful business names (e.g., Verify Contract Terms).
Document input/output parameters and their expected usage.
Keep subprocesses focused on a single responsibility or outcome.
Avoid designing subprocesses with assumptions about the parent context.

Naming conventions

Subprocess and call activity names should:

Use business language, not technical terms
Describe the outcome (e.g., Collect Customer Data, not Form Step 2)
Reflect what the subprocess accomplishes, not how.

Not supported

Expanded subprocesses (i.e., inline subprocesses) are not supported. All subprocesses must be modeled as separate diagrams and invoked using Call Activities.
Ad-hoc subprocesses are not supported.
Implicit variable sharing is not supported. Data must be explicitly mapped through input/output bindings.

Multi-instance markers

Subprocesses support multi-instance markers, where each element is executed multiple times. The elements that can be marked as multi-instance are all task types except for subprocesses.

Nested markers

The following string variables are supported as nested iterators:

Category	Attributes	How to use/access
OuterSP - Get Contact Information for each user	`InputCollection`	`var.GetUsers`
OuterSP - Get Contact Information for each user	`Iterator Item`	`iterator.item.gid`
InnerSP - Get all emails for each contact	`InputCollection`	`iterator[0].item.contactArray`
InnerSP - Get all emails for each contact	`Iterator Item`	`iterator[1].item.ContactId`
Send Email	`InputCollection`	`iterator[1].item.EmailArray`
Send Email	`Iterator Item`	`iterator[2]item.emailAddress`