Quick setup checklist
Use this checklist to limit retries on questions and route contacts after a fixed number of incorrect attempts.
Use this pattern when you want to limit how many times a contact can attempt to answer a question.
It’s especially useful to:
- Limit guessing in quizzes
- Prevent endless retries on validation questions
- Control how many incorrect responses are allowed
- Provide a fixed number of attempts before moving on
Tip: This method works best immediately after a Wait for Response node.
A common structure is:
- Ask a question using Wait for Response
- Evaluate the answer
- If incorrect, route to a retry limit using Split by Expression
[CAPTURE: Show a simple flow with Wait for Response followed by Split by Expression.]
Use a Wait for Response node to collect the contact’s answer.
- Correct answers should exit via the Correct path
- Incorrect answers should exit via the Other path
If the answer is correct on the first try, the contact continues without restriction.
On the Other (incorrect) path, add a Split by Expression node and use @node.visitcount.
Then apply a rule such as:
- has a number above 1
This rule means the contact has already made two attempts, so no further attempts are allowed.
[CAPTURE: Show the Split by Expression node with @node.visitcount and a rule set to has a number above 1.]
Important: The visit count includes the current visit. A rule of above 1 allows only two total attempts.
Typical behavior looks like this:
- Correct on first attempt → contact continues
- Incorrect on first attempt → contact is given a second chance
- Incorrect on second attempt → contact exceeds the limit and is routed accordingly
[CAPTURE: Show the simulator with a contact failing twice and being blocked from further attempts.]
You can include the visit count in a message to communicate progress or limits.
Example: You have used @(node.visitcount/2) attempts.
This is useful when:
- Allowing more than two attempts
- Clearly communicating limits to contacts
[CAPTURE: Show a message node displaying the number of attempts using @node.visitcount.]
Tip: Divide by the total allowed attempts to show progress (for example, @node.visitcount/3).
Important:
@node.visitcountapplies only to the current flow run- If a contact is restarted in the flow, the count resets to 0
- Visit counts are not stored across multiple runs
Common Issues
The retry limit triggers too early
Cause: The rule threshold does not match the number of allowed attempts.
Fix: Remember the count includes the current visit. For 2 attempts total, use has a number above 1.
@node.visitcount is always 0 after restarting the flow
Explanation: Visit count applies only to the current flow run and resets on restart.
Fix: If you need persistence across runs, store an attempts counter in a contact field instead.
Contacts can still retry endlessly
Cause: The Split by Expression is not placed on the incorrect path or the incorrect path loops around the protected node without passing through the split.
Fix: Ensure the Other path routes through the split before returning to the question.
The message showing attempts looks confusing
Cause: The expression divides by the wrong total attempt count.
Fix: Divide by your allowed attempts (for example, @(node.visitcount/3) for 3 attempts), or show raw count with @node.visitcount.