Sub Workflows (examples)
A sub workflow is simply a workflow that was started by another workflow.
That in itself is trivial, but you can do it in two different ways.
Asynchronous Sub Workflows (automated)
Let's look at the following simple workflow.
When this workflow is started, it automatically goes into the transition (which contains no conditions), where a sub workflow is started.
Import: (instructions)
Workflow_WF_sub_wait.xml (import first)
Here is the simple sub workflow. When it is started, it also automatically goes into the transition, waits for 60 seconds, and then terminates.
What is the behaviour of the parent workflow?
After the parent workflow starts the sub workflow, it simply terminates, i.e. it does not wait for the sub workflow to finish. The sub workflow then terminates after 60 seconds. So you see the parent workflow immediately in the logs and the sub workflow for 60 seconds in the jobs and after that in the logs.
Synchronous Sub Workflows (automated)
So what can be done if we want to wait in the parent workflow until the sub workflow is finished?
There is no direct mechanism for this in the current workflow framework, but there is a little trick we can use to achieve this.
Import: (instructions)
Workflow_WF_sub_wait.xml (import first)
The first step is like in the asynchronous example, i.e. we start the sub workflow (you can use the sub workflow from above).
After that, however, we add a state with automatic transition check and waiting time, i.e. the following transition is checked initially and then cyclically until the end of the waiting time.
In the transition, we only use function workflow exists(a) to check whether the sub workflow still exists. And only if it does not exist anymore, the conditions of the transition are fulfilled and the parent workflow terminates as well.
So you will see both workflows in the jobs for about 60 seconds (the parent workflow may run a little longer because of the cyclical check) and then both in the logs.
Note about variables
The variables of the parent workflow are passed to the sub workflow (but not all). In the sub workflow, the variables of the parent workflow can be changed, but for this you have to pass the ID of the parent workflow in a special way, because it is not passed directly to the sub workflow. See the documentation of function add/set workflow variable(a,b,c,d) for this.
Why sub workflows?
If you have a simple/manageable task to solve, there is usually no need to use sub workflows. It may even be better not to use them.
However, if you are confronted with a complex task, it can make sense to break it down into subtasks and possibly these subtasks again into subtasks. This facilitates modelling, increases clarity, and also simplifies the technical implementation in the final step. (In addition, if you trigger several sub workflows, they run in parallel, which can be a significant performance advantage.)
If a subtask has been triggered at the highest level, in some cases it will be necessary to continue only when the triggered subtask has been completed. And for this purpose synchronous sub workflows can be used.
Sub Workflows in Profiles
So far we have looked at everything from the perspective of workflows. But we can also turn this around, i.e. we use a profile and start one or more workflows in it with function start new workflow(a,b). In principle, the profile then has sub workflows.
See section Profiles as Workflow Master.