Secondary Flows

A template always contains a main Flow that defines its main logic, but it is not necessarily the only Flow. There can be other Flows that can run during the evaluation process, working as parts of the main Flow. These Flows are structurally the same as those working as main Flows, but their design is typically a bit different, as they're not intended to work alone.

Subflows

Any Flow may direct the evaluation process to a Subflow through the use of a Flow step. When a Subflow starts, the Flow initiating it is stopped for the duration of the Subflow. When the Subflow finishes, the initiating Flow continues on from the Flow step. The Subflow has access to the same variable context as the initiating Flow, and so may read or overwrite any variables created in the initiating Flow and its created variables can be accessed in the initiating Flow. The Subflow can do anything the main Flow can - even initiate another Subflow - and so Subflows can be used for a variety of purposes.

Perhaps the most notable role of Subflows is to act as reusable parts of the evaluation process, as the same Subflow may be evaluated several times in the evaluation process. A Subflow might, for example, perform a document-saving procedure, so whenever the main Flow requires having the document saved, this Subflow would handle it.

Screen component Flows

A Screen component Flow is named as such for its role to act as the host for logic behind a part of the main Flow's screen. This kind of Flow is linked with the HTML content command flow-runner, whose function is to trigger the evaluation of a Screen component Flow and define the element in the screen that will display the Flow's progress and its own screens. As the name hints, the main idea behind these Flows is that their Screens are essentially parts - components - of the main Flow's Screen. Such a component might be, for example, a two-stage selection, in which you select something and then based on this selection, another set of selections appear; something like this would be easy to see as a Flow with two Screens, with logic between them defining the selections of the second Screen.

To act as a component in the main Flow's Screen, a Screen component Flow can be designed so that it never finishes. The aforementioned two-stage selection example could loop back to the first Screen after the second. If a Screen component Flow finishes, the space reserved for it will then just display the conclusion message, as these Flows cannot be restarted.

A Screen component Flow is intended to be its own individual unit, and so it will not share the variable context with the main Flow. It also has no access to inputs in the main Flow's Screen structure. However, it is able to send values to the main Flow and the Screen in which the component Flow's component is in. This it can do with Screen data, by creating new Screen data variables, or modifying any Maps or Collections among the Screen data variables of the main Flow. This is described in more detail in the Screen data documentation page.

Background Flows

A Background Flow can work in the background of the main Flow's Screen to execute logic tasks altering the Screen. This kind of Flow is linked with the HTML content command flow-click, that will start the evaluation of a specific Background Flow with a simple click. A Background Flow can work with data from the Screen's inputs as well as the main Flow's variables to do something, and then return the results of its work back to the Screen.  A Background Flow could therefore, for example, make use of the user's current input to query and process external data to refresh data on the Screen, recreate a PDF document displayed on the Screen, or perhaps save the user's work to an external database - all without the need to move out of the current Screen.

The evaluation process of a Background Flow starts out with a copy of the main Flow's variable context in the state it was before the current Screen step, therefore having access to all the main Flow's variables. It also receives the current values of the inputs in the main Flow's Screen, in the exact same way as the main Flow receives their values when the Screen is submitted. With the Background Flow's variable context being but a separate copy of the main Flow's context, any changes done to it are not reflected in the main Flow.  

A Background Flow should be designed so that it finishes, in contrast to the Screen component Flow which typically should not finish. Upon finishing, any variables created within the Background Flow that are declared as Screen data are sent to the Screen, adding or overwriting existing Screen data variables. These Screen data variables are sent upon finishing instead of alongside a Screen because a Background Flow may not contain any Screen steps. The evaluation of a Background Flow will produce an error and stop if it ends up on a Screen step.