What should happen to later answers when a user changes an earlier choice in a branching form?

When a user changes an earlier branching answer, any later answers that depended on the old path should stop counting immediately. Keep them as recoverable draft data if that helps backtracking, but exclude them from validation, review, and submission until the user reconfirms the branch. In practice: separate “stored draft answers” from “currently applicable answers,” then show a review step with explicit change links before submit, as recommended for multi-step and check-answer flows by W3C WAI and the GOV.UK Design System.

What should be invalidated when an earlier answer changes?

Invalidate every descendant answer whose meaning depends on the changed choice. This is not just about hidden fields in the current screen. It includes later steps, derived summaries, eligibility outcomes, and any validation state attached to those answers.

The safest rule is: if the user could not have reached that question on the new path, that answer is no longer active. Do not silently submit it. Hiding stale answers while keeping them in the payload is how branching wizards produce incorrect applications, prices, or approvals.

This fits the structure of multi-step forms: W3C WAI recommends splitting forms into “logical groups of controls” and letting users review completed steps. Once the logical group changes, downstream groups need to be reconsidered.

Should you delete those answers or keep them for backtracking?

Usually keep them in draft storage, but treat them as inactive. That gives you the best of both behaviors:

• good backtracking UX if the user flips back to the previous branch
• no stale data in validation or final submission
• a clear audit trail of what still needs reconfirmation

A useful model is to store each answer with an applicability condition and a confirmation state. If applicantType = company makes companyNumber applicable, and the user switches to individual, keep the old company answers in local draft or server draft, but mark them inapplicable. They should disappear from the active review page and from the submitted payload.

What should the user see after the branch changes?

Tell them what changed, then route them to the next unresolved step. If the branch shortens, progress can decrease or total steps can change. That is acceptable as long as progress remains explicit. W3C WAI notes that step counts may depend on user input and should still communicate progress clearly.

On the final review page, show only active answers and provide change links for each section. The GOV.UK Design System explicitly recommends letting users “Check your answers before sending” information. That review step is where hidden stale answers must be impossible to miss, because they should not appear at all.

Worked example: switching applicant type

Suppose your flow is:

1. Applicant type: Individual or Organization
2. If Organization: legal name, registration number, billing contact
3. If Individual: date of birth, home address
4. Review and submit

If the user completes the organization path and then changes applicant type to Individual, do this:

• mark organization fields inapplicable
• remove them from active validation errors
• remove them from the review page
• omit them from submission
• send the user to the first required unanswered individual step
• optionally preserve the organization answers in draft in case they switch back

That policy prevents hidden organization data from silently determining the final submission.

Follow-up: should progress decrease?

Yes, if the branch became shorter or the current path changed. Do not fake monotonic progress. Show the updated step count clearly.

Follow-up: when must answers be reconfirmed?

Require reconfirmation whenever an earlier change can alter the interpretation, necessity, or legality of a later answer. If a summary section was affected, send the user back through the affected path and require review again before submission.

Your next step: write a dependency map for every question in the wizard, and implement submission from applicable answers only—not from every value still sitting in form state.

Reviewed: 2026-09-05.