The Flow is the template part in which the template's logic resides, but it's also the topmost structure of the logic that defines the paths of the evaluation process. Although many Dynamo templates follow a certain model structure with their Flows, logic creators are allowed to shape the Flow however they like.
With all the structural layers in place, the progress of the Flow's evaluation process from start to end is as follows. On the Segment level, the evaluation proceeds from Segment to another in a strict, absolute order, with the Flow itself finishing when the last Segment ends. Within each Segment the evaluation proceeds from Step to another in either a fixed or variable order, with the Segment finishing once a Step finishes without declaring a follower. Within each Step the commands are evaluated in a relatively straight sequence, with the Step finishing when its command sequence ends.
Of all these structural layers through which the evaluation process goes through, the most fluid paths are found among the Steps. Steps can connect to multiple other Steps, they can skipped, or even repeated. This route through the Steps is mainly defined by the control command next placed within the Steps themselves. This essential command can be found belonging in the "Flow" group in the Step editor's left-hand panel.
In the Template editor's Segment view the arrows connected to the Steps represent the effects of the next
commands. An arrow pointing out of the Step indicates that the Step contains a next
command, pointing the path towards the Step named above the arrow. In the image below the Step "Compose - Start" is followed by Step "Compose - End".
If you then take a look at the commands within "Compose - Start", the corresponding next
command (which the editor displays as "Go to") can found at the end of the sequence. Changing or deleting the command here would also change or remove the arrow in the higher-level view.
The only attribute of the next
command is step
, which defines the Step the evaluation process will head to by the Step's ID. Any Step within this Step's own Segment can be defined - even the Step itself (but be careful to not create an infinite loop - that will lead the evaluation process into an erroneous end).
A Step may contain more than one next
command, allowing the evaluation process to proceed into more than one possible direction. As the evaluation process cannot split into multiple directions at once, this requires the use of conditions that define which of the various next
commands takes effect. As might be expected, with multiple next
commands present, the Template editor displays multiple arrows pointing out of the Step.
The command sequence of the Step then contains the corresponding commands nested within a conditional structure.
Screen steps, not containing any commands and therefore unable to have the next
command, define their following Step in a somewhat different manner. Their equivalent of the next
command is a logic attribute of the same name - next. This logic attribute can be placed into any submit button on the Screen and like the command, it specifies the ID of the Step the evaluation process should head to. To have multiple routes out of a Screen step, there can simply be multiple buttons with the next
logic attributes pointing to different Steps.
In the Template editor head to a Screen step and click any button on the Screen to see the possible logic attributes for it. The one displayed as "Next Step" is the logic attribute talked about here. Additionally, there's "Next Message" - this defines a message that will be displayed while the next Step is being loaded.
If the command sequence of a Step doesn't contain any next
, or none of the next
commands there are evaluated due to conditions surrounding them not succeeding, the end of the command sequence will also finish the Segment. The equivalent of this in a Screen step is clicking a submit button that does not have the logic attribute next
defined.
While the routes between Steps are defined through the command and logic attribute next
, the first Step of a Segment's evaluation has to be defined in a different manner. This uses a value provided to the Flow evaluation process at the time of its creation called "Event". Any Step may be set as the starting Step corresponding to a specific Event, and one Step may be set as the default starting Step, which will be the first Step if the Event value doesn't lead to any other Step becoming the first.
In the Template editor the Event-defined first Steps are defined by blue arrows pointing towards the Steps. The Event value leading to the Step is displayed above the arrow.
In the case of the Steps above, Event "rerun" would cause "Check history" becoming the first Step, while "firstRun" makes "Prepare first run" the first Step. If the Event value is anything else, "Prepare first run" will be the first Step, since it is set as the default starting step as indicated by the arrow "default" pointing to the Step. As shown here, multiple Events may also lead to the same Step.
If a Segment doesn't specify a starting Step for the evaluation process' Event value and the Segment doesn't have a default starting Step, no starting Step can be defined and the evaluation process will skip the Segment.
Any Step may contain an error-handling route that immediately directs the evaluation process into another Step should a command in the current Step produce an error. This can be useful if a Step has a command or another that can be expected to fail in some cases, while also having effects critical to the operation of following commands. The Step at the end of the error-handling route could be a Screen informing the user of the error, or it can lead the Flow into a different path that skips Steps with commands that would now also fail due to the original error.
In the Template editor these error-handling routes appear as red arrows pointing out of the Steps. Similarly, a Step that is the error-handler of another Step has a red arrow pointing into it. Below you can see the Step "Initialize" having an error-handling route defined. If all the commands within the Step are evaluated without problems, the evaluation process goes into "Define Formats", but if an error occurs, the evaluation process will go into "Initialization Error" instead.
If a Flow is evaluated in an environment in which user input is not possible, such as through the Dynamo API, any Screen steps will automatically be skipped. Skipping a Screen step has the following effects on the evaluation process: