Repository navigation
Clarify the structure and usage of run.workflow for sub-workflows #1122
Description
I tried this:
Description:
In the schema, there is a run.workflow element that defines a sub-workflow.
However, it’s not entirely clear how this definition is supposed to be used.
The workflow definition currently specifies the following properties:
namespacenameversioninput
As I understand it, a sub-workflow should behave similarly to a regular workflow — meaning it should at least contain a do definition or some equivalent execution logic.
It would be helpful to clarify:
- whether a sub-workflow must include its own
dosection, - how it inherits or overrides inputs/outputs,
- and how its execution context is handled relative to the parent workflow.
This happened:
I can define sub-workflow
I expected this:
No response
Is there a workaround?
No response
Anything else?
No response
Area(s)
No response
Community Notes
- Please vote by adding a 👍 reaction to the issue to help us prioritize.
- If you are interested to work on this issue, please leave a comment.name: Bug Report 🐞
Activity
cdavernas commentedon Oct 22, 2025
@treblereel A subflow is simply a task that runs another workflow. The invoked workflow is indistinguishable from any other—it can also be executed independently. Because of that, it must follow the same rules as other workflows, including defining at least one task in its do section.
A subflow doesn’t automatically inherit or override data from its parent. Instead, it receives as input whatever data you choose to pass to it—by default, that’s the current data of the calling workflow. Its output is then returned to the parent upon completion.
The subflow runs within the same execution context as its parent. It should therefore be terminated, cancelled, suspended, or resumed along with the parent, unless it’s explicitly not awaited.
I hope this clarifies things.