Routes through The Flow (Legacy)

From Step to Step, from Segment to Segment - that is the Flow's progress in a nutshell, but the actual route through these components can vary a lot between Flows. As one can fully customize what kind of Steps can be found within the Flow, so can one customize the routes between these Steps, and even make them dynamic. In general, the routes are defined by the Steps themselves, as they declare their following Steps.

From Step to Step

One of the core tags of the Flow model is next. It specifies the ID of another Step within the Segment and upon evaluation, causes the Flow to move on to the specified Step. As this may imply, all Steps need to have an ID that is unique within the Step's Segment.

Forms, not usually containing tags, can do the same task by specifying the following Step in the buttons within the Form.

Note that both of these methods enable the creation of multiple routes out of the Step - with normal Steps next tags can be placed into suitable conditional blocks to ensure only one is evaluated, and Forms can simply have multiple buttons. This is how a Flow can have varying routes through it. A Step can even route back into itself, but be careful in designing potentially looping or otherwise complex webs of Step routes - a Flow will automatically stop if it has moved through 100 Steps.

Another kind of route that exists is taken when an error occurs. A Step may have another Step specified to which the Flow heads should an error occur during evaluation. The error Step may, for example, be a Form displaying a customized error message and maybe further direct the Flow to a different route to handle the error. Even the best designed Flows may encounter errors at times - downloading a file may fail, for example - so definining these error routes can be a good idea.

From Segment to Segment

While Steps can move between each other like this, they can only link with Steps in the same Segment. To end the current Segment, a Step simply has to not declare a following Step. The Flow then proceeds to the next Segment. But which Step will be the first one of the Segment? That is defined by the Flow's initiating event and Segment's event mappings.

As a Flow starts, the name of an event can be given with other starting parameters. All Segments receive this event name and may then select the starting Step based on it. In a simple case a Segment has the same starting Step for all events, like here.

If no event is specified by the command starting the Flow, the event will by default be 'new', indicating that the Flow is run to create a new document or such. Any event names can be freely defined - as long as the event parameters match with the event names understood by the Segments, the names themselves don't actually matter.

It is also possible to create a "catch-all" event mapping. In the case that the current event name doesn't match any of the other mappings, this universal mapping will take effect and lead the Flow to the Step it declares. While primarily useful for making Segments that are guaranteed to work with any event names, this mapping can also be useful in Flows in which some Segments react differently to various events, but in some Segments all these events should share a common route.

Learn how to connect Steps in the Flow