Page History

...

Because of the 'previous' event, which will route the user back to the last visited page, the return route is not modelled when using free flow naviationnavigation. Instead the return button on the page get's a Validate gets a Validate and Continue event named Previous. In free flow we can use the validate and continue event type while navigating the menu items since the validations will not hinder the user's flow but will only assist in keeping track of the pages the user has visited, but that contain contains invalid or incomplete information.

...

Each free flow menu item will correspond to a flow of type SinglePageFlow. This suggests that the single page flow can only contain a single page, which is not entirely true. We do expect the single page flow to have one 'landing' page for the menu item. From that landing page users can navigate to other pages in the single page flow, but they can not navigate to other menu items while doing that. So in the model the menu should be disabled. A typical usecase for this type of navigation is when the menu landing page contains an instance list and new instances will be added on a separate page. In this case the menu can temporarily be disabled when the user fills out the information in the instance and retuns returns to the menu landing page to continue the free flow.

...

Before the availability of the FreeFree flow FreeFlow in Blueriq you were also quite able to create such a navigation model. This however had a lot of drawbacks. To accomplish it a lot of boilerplate modelling had to be done, that didn't account to the actual business goal of the application. And because of all this boiler plate modelling, maintaining and testing your model grew in effort significally. 
With boiler plate modelling we mean that:

• the navigation container had to be custom made, including a front-end theme , with extensive conditionality
• the navigation 'options' had to be modeled, usually decision tables were abused for this (abused because it mixes business logic with interaction logic)
• validation rules were commonly duplicated, for handling the blocking and non-blocking situations that the attributes had to be able to deal with
• the flow model was overly complicated because all the options had to be explicitly modeled, also troubling the readability of the model and thus troubling maintainability
• the navigation model had to be put into the domain, in order to model the decision tables and use it in the flows. Again mixing business knowledge with interaction knowledge

...