Logic

Step-level settings

Steps can be conditionally rendered based on previous answers, and have their own set of logic that can affect the navigation of a flow, such as preventing forward navigation or back navigation.

Show conditionally

Use this to render or hide the step based on answers the user has given earlier in the flow. Logic cannot be set based on answers that come after the step. See conditions and logic for more information.

Disabling back navigation

If Disable back navigation is checked on a step, users will not be able to go back backwards in the flow once they have reached the step. If a previous button is included in your Layout it will be hidden, and URL navigation (the browser's back button) will not work.

This is helpful if you do not want users to be able to change their answers once they reach a particular point in a flow. For example, if a user has chosen a product and paid for it, you may want to disable returning to any previous steps.

Disabling forward navigation

If Disable forward navigation is checked, the responder will not be able to continue forward in the flow once they reach the step. This is helpful if you have collected enough information to determine that you cannot proceed, but have no website to redirect a user to.

Since it is not possible to advance from a finalizing step or a step with forward navigation disabled, it is not possible to collect answers on such steps.

You can still use content blocks such as images or informational content.

Finalizing steps

If Is finalizing? is checked, the step will have the following characteristics:

• When loaded, the FlowFinalized event will be emitted to your analytics endpoints.

• When loaded, an answer payload with a finalized: true field will be delivered to answers integrations.

• The user will not be able to advance forward in the flow, and as a result no redirect can be added to the step.

Since FlowFinalized is emitted at step loading, no answers can be collected on this step.

Recipes

Collecting an email from a disqualified responder (waitlist)

A common pattern is to disqualify a user, but to ask for some additional information from them for a waitlist or to follow up later.

To implement this, one approach can be:

1. Use a calculated answer or api answer determine if the user cannot continue based on their other answers, calling it something like is_disqualified

2. Add a step that contains the waitlist questions (such as an email question to follow up at, which we will call waitlist_email), with a condition of is_qualified Equals true. This will result in the step only being shown to disqualified users, but they will be able to add answers and continue beyond it.

   If you do not want users to go back and change their answers (to prevent "gaming" of the qualification), you can check Disable back navigation so that they cannot go back to change their answers.

3. Add a following step that has Disable forward navigation checked, and is conditional on the email being collected, such as waitlist_email Is defined. This step cannot contain questions that collect answers, but it can contain content such as informational blocks, which can be used to thank the responder for their time.

   If it's helpful for you, also check Is finalizing so that your integrations get FlowFinalized events for this step.

[Legacy] terminal steps

The "Terminal" behavior is a legacy feature and is not available for new steps. See either finalizing or disable forward navigation, described above, for more control over when a flow ends early.

If you mark a step as Is terminal, once a responder reaches this step, they will not be able to continue. This was useful when building qualification flows where you might not want everyone to complete the flow: it was equivalent to a step with only "Disable forward navigation" set today, although it allowed for answers to be collected, which was buggy.