- Introduction
- Getting started
- Process modeling
- Process implementation
- Process operations
- Process monitoring
- Process optimization
- Reference information
Maestro user guide
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, notForm 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 |
For more details about the BPMN elements supported in Maestro, see BPMN support.
