Publishing and Status of Subflows
Subflows – IF branches and function blocks – are internal components of their caller. Therefore, they behave differently from normal flows when published and in the status display.
Publishing
When publishing a flow, a separate execution copy is created for each instance of a subflow:
- for each IF branch of the conditional transfer object,
- for each call site of a function block.
Static variable values from the caller are hard-coded into the copy. The runtime executes only these copies—the editable definition itself is never published directly. Changes to branches or blocks therefore take effect only when the calling flow is published again (phased rollout, as with template instances).
Display in the Publish Tree
The copies appear as read-only entries (cube icon) below their calling flow—with their own change indicators (added/changed/unchanged):
- They cannot be selected individually. Selecting the calling flow automatically publishes its sub-flows as well.
- Clicking on an entry opens the usual preview, showing the difference between design time and runtime.
- Sub-flows do not appear as normal flows in the tree’s folders.
Cleanup
If a reference is no longer used (e.g., the calling transfer object was deleted or switched to a different module), the corresponding runtime copy is automatically removed from the runtime the next time the calling flow is published.
Note when updating from earlier 5.7 pre-release versions: The first publish after the update may include a one-time cleanup that removes older copies. This is intended.
Status and Diagnostics
Status Tree
Sub-processes do not appear as separate entries in the status tree. Instead, the calling flow displays a notification badge as soon as one of its sub-processes reports a problem:
| Badge | Meaning |
|---|---|
| Red with number | Number of sub-flows with an error state or a failed transfer. |
| Yellow with number | Number of sub-flows with an aborted transfer. |
The badge’s tooltip explains the meaning. If all sub-flows are running without errors, no badge is visible.
Transfer Details
In the transfer details of the calling flow, the caller transfer object (condition or function module call) displays the call’s diagnostics:
- called target and—in the case of an IF—selected and skipped branches,
- result status and duration of the sub-process transfer,
- in case of errors, the error message from the sub-process,
- the transfer context ID of the sub-process run (can be copied for detailed investigation).
An error in the subflow causes the transfer of the calling flow to fail; a branch skipped due to a missing condition is not considered an error.
Open Subflow Status in the Diagram
In the status view of a flow, the caller’s node (condition or function block call) features an action bar that reflects the result of the subflow:
- Condition (IF): one Open THEN button and one Open ELSE button. The branch executed in the selected transfer is color-coded according to its status (green = successful, red = error/timeout, yellow = rejected/flow not ready). The unexecuted branch remains grayed out (tooltip: “This branch was not executed”).
- Function Block Call: a Open FB button, colored according to the result of the call. It is disabled if there is no associated sub-flow transfer.
Clicking an active button (Open Sub-Flow Status) opens the read-only status diagram of the executed sub-flow as an additional tab below the diagram, named after the sub-flow. The tab:
- displays the execution of the sub-flow with the same status information as a normal flow,
- follows the transfer selected in the caller and updates in real time,
- allows for nested expansion—from a sub-flow’s status diagram, you can open deeper-level sub-flows in the same way,
- can be closed again using the ×.
If the sub-flow was not executed in the selected transfer (e.g., a skipped ELSE branch), the tab indicates this: “This sub-flow was not executed in the selected transfer.”
Time Limit and Parallelism
The time limit configured on the caller applies to each call. If this limit is exceeded, the caller’s transfer fails and the sub-flow is aborted before the next call begins. For each execution copy, at most one call runs simultaneously; parallel call sites of the same function module operate independently of one another thanks to their own copies.