#Group steps in a sub-process

A sub-process runs its inner steps as a separate part of the instance that sees only the inputs you pass in, and hands the results of those steps back under its own id.

#What happens when the process reaches it

flowchart LR
  subgraph Parent["The process"]
    A["Fetch customer"] --> SP["Sub-process<br/>SubProcess_check"] --> N["Next step reads<br/>SubProcess_check.Activity_score.value"]
  end
  subgraph Child["Inside the sub-process (its own part of the instance)"]
    S(("Start<br/>StartEvent_in")) --> T["Activity_score"] --> E(("End"))
  end
  SP -- "Input parameters →<br/>StartEvent_in.customerId" --> S
  E -- "results of the inner steps" --> SP

The steps inside do not see the data of the process around them — not the start data, not the results of earlier steps. They see only:

• the input parameters you fill in on the sub-process, stored under the id of the inner start event — for example StartEvent_in.customerId;
• the person who started the process, as __INITIATOR.

The process waits at the sub-process until its inner part reaches an end event. An end event inside finishes only the inner part; the process then continues. See End a process.

#Configure a sub-process

1. Inside the sub-process, select its start event and open Input schema. Describe the fields the inner steps need — see Work with process data.
2. Select the sub-process itself and open Input parameters. It shows one field per input-schema field, required ones first. Fill each with a value, a variable from earlier steps, or an expression.

Without an input schema the group says "No input schema defined at the start event." and the inner steps start without data.

Collapsed and expanded sub-processes behave the same.

#Run it once per item

Switch on Enable multi-instance in the Multi-instance group to run the inner part once per item of a list — Collection type: Context variable for a list from the process data, User group for the members of a group.

The inner steps do not see the list either. Pass the current item in explicitly: set an input parameter to __loop.item, or __loop.index for its position.

For a sub-process the completion rule is fixed to all runs. One failing run fails the whole sub-process.

With Sequential, the runs happen one at a time: the next starts once the one before has ended.

⚠️ The labels Sequentiell, Collection Quelle and Abschlussbedingung are German whatever the language of the screen. See Run a step once per item.

#What the sub-process hands on

Under the sub-process's id the next steps find the result of every inner step, by that step's id — including the inner start event, so the inputs come back too:

• SubProcess_check.Activity_score.value
• SubProcess_check.StartEvent_in.customerId

A multi-instance sub-process hands on a list, one entry per run in the order of the collection: SubProcess_check[0].Activity_score.value. An empty list hands on [], and the process continues.

#When a step inside fails

When the inner part fails, the sub-process fails with the message "Child workflow completed with error". The message of the step that failed inside is not passed up; it is in that step's history in monitoring.

• An error boundary event on the sub-process catches it — any failure, there is no filter by code.
• Without one, the instance fails. Retrying the step inside from monitoring continues the sub-process and the process around it.
• ⚠️ An error end event inside does not fail the sub-process. It ends the inner part normally.
• Cancelling the instance also cancels the inner part.

In monitoring, the sub-process row expands to show the steps inside. The inner part is not listed as an instance of its own in the instance list.

#Variants

#Limits

• ⚠️ Nesting stops at 10 levels, counting sub-processes and call activities together.
• ⚠️ No time limit. A step inside that waits — a user task, a message — keeps the process waiting at the sub-process for as long as it takes.
• ⚠️ Required inputs are not enforced. An empty required field is only marked in the panel; nothing stops the deployment or the run, and the inputs are not checked against the schema.
• ⚠️ An input whose expression cannot be worked out fails the sub-process at once.

#What validation checks

There are no rules for the sub-process itself beyond valid expressions in its input parameters. The steps inside are checked like any others.