Goto (flow concept)

Goto describes the process of jumping from one step to another independently of the configured step order.

A Goto jump has a source step and a target step.

• Source step
• A source step can have several potential Goto targets. They are configured in the source step.
• Pre- and skip conditions of source steps are evaluated: If the evaluation of a precondition fails, the flow is aborted. If the evaluation of a skip condition succeeds, the step is skipped.
• Source steps that are left by a Goto are aborted in the sense that they will not provide a successful step result and therefore will never add tags to the flow.

• Target step
• The target step has a step ID, which must be unique within the flow. 
• Pre- and skip conditions of target steps are evaluated. 
• If the evaluation of a precondition fails, the flow is aborted. If the evaluation of a skip condition succeeds, the step is skipped and flow processing continues normally.

Goto jumps to steps other than the configured targets or to targets outside of the flow are prohibited.

For interactive steps, the Goto target's endpoint can be used to instruct the flow processor to continue with a different step. The target step may be interactive or non-interactive.

• Example:
• An authentication flow has been started and the user is on the Username Password Authentication Step.
• The user provides the correct credentials and the flow automatically continues to the mTAN Authentication Step.
• The user decides to use a different second factor.
• Using the Goto-Targets endpoint the list of possible target steps is retrieved. The user selects email OTP from the list.
• Using the Goto-Target endpoint the flow is instructed to continue flow processing with the chosen target step.
• The user receives an email, provides the correct code, and is then authenticated.

For every flow type, a REST endpoint supporting two methods is exposed. They are used to retrieve possible Goto targets and follow a goto, i.e., tell the flow state machine what step to process next.

• .../goto-targets/retrieve/ – retrieve all valid Goto targets steps for the current step.
• .../goto-targets/<stepId>/goto/ – jump to the specified Goto target step.

Gotos can be triggered programmatically by any flow step. In this case, this step will act as a Goto source.

For non-interactive flow steps, the programmatically triggered Goto is the only way the step can act as a Goto source: The Goto target's endpoint cannot be used for this step, as flow execution is non-interactive (not REST calls).

A programmatically triggered Goto may use both interactive and non-interactive steps as Goto targets.

Custom steps
Custom step config classes need to extend AbstractInteractiveFlowStepConfig to be capable to perform an interactive Goto. Internal Gotos can always be performed by adding an InternalGotoTargetConfig to any custom step config and implementing the getInternalGotoTargets() method to return these targets.

It is possible to configure Gotos as a failure. This has the same effect as a normal Goto but can lead to increased failure counters. In flows that support failure counters, e.g. authentication and transaction approval flows, executing a failing Goto leads to increasing the currently active failure counter on the database, possibly locking the user.

Example:
Using a failing Goto in the authentication example above prevents the user from unlimited switches between mTAN and email OTP. This prevents an unlimited number of SMS messages from being sent.