You may want to set a limit to the number of times a contact can respond to a specific question in your flow, such as with a quiz or survey. You can do this by using the @node.visit_count expression within a Split by Expression action.

In the example below, we've created a very simple quiz. We want the contact to have limited opportunities to answer the question, so we will place the @node.visit_count expression on a 'Split by Expression' node to limit the number of guesses.

In the flow above, we see that after collecting the contact's response with a 'Wait for Response', we're evaluating their answer with a 'Split by Expression'. Since we only want to give the contact two opportunities to answer correctly, here's how we've written the expression and rule:

We've used the expression @node.visit_count and then written a rule with has a number above 1 since they've already used their one other attempt in the previous 'Wait for Expression', equaling two total attempts.

What this means is that if they've answered correctly on their first try, they'll be routed through the 'Correct' exit on the 'Wait for Response' node and get a congratulatory message. If they get their first try wrong, they'll be routed through the 'Other' exit where we've set a limit to the number of times the contact can be wrong. Because the visit count is set to a number above 1, no further attempts are permitted.

We can see how this works via the Simulator. This contact gave an incorrect response on their first attempt and was given a second and final opportunity to answer correctly. Because we set a @node.visit_count limit of above 1 via a 'Split by Expression' node, their second incorrect answer means they've used up all their tries.

Another contact, however, studied a bit harder:

Notice that in our follow-up message, we've referenced the number of tries the contact has made. We did this by using the same expression written as `@node.visit_count`/2. This would be especially useful if the contact had even more chances to respond correctly so they know how many opportunities remain.

Keep in mind that visit_count reflects only the current flow run. This means that if the contact is restarted in the flow, the count goes back to zero as counts from previous runs are not saved.

Try building your own flow logic to test this out! Questions? Send us a message via the support widget in the bottom right corner of your browser.

In the example below, we've created a very simple quiz. We want the contact to have limited opportunities to answer the question, so we will place the @node.visit_count expression on a 'Split by Expression' node to limit the number of guesses.

In the flow above, we see that after collecting the contact's response with a 'Wait for Response', we're evaluating their answer with a 'Split by Expression'. Since we only want to give the contact two opportunities to answer correctly, here's how we've written the expression and rule:

We've used the expression @node.visit_count and then written a rule with has a number above 1 since they've already used their one other attempt in the previous 'Wait for Expression', equaling two total attempts.

What this means is that if they've answered correctly on their first try, they'll be routed through the 'Correct' exit on the 'Wait for Response' node and get a congratulatory message. If they get their first try wrong, they'll be routed through the 'Other' exit where we've set a limit to the number of times the contact can be wrong. Because the visit count is set to a number above 1, no further attempts are permitted.

We can see how this works via the Simulator. This contact gave an incorrect response on their first attempt and was given a second and final opportunity to answer correctly. Because we set a @node.visit_count limit of above 1 via a 'Split by Expression' node, their second incorrect answer means they've used up all their tries.

Another contact, however, studied a bit harder:

Notice that in our follow-up message, we've referenced the number of tries the contact has made. We did this by using the same expression written as `@node.visit_count`/2. This would be especially useful if the contact had even more chances to respond correctly so they know how many opportunities remain.

Keep in mind that visit_count reflects only the current flow run. This means that if the contact is restarted in the flow, the count goes back to zero as counts from previous runs are not saved.

Try building your own flow logic to test this out! Questions? Send us a message via the support widget in the bottom right corner of your browser.

Updated on: 13 / 12 / 2021