Conditional Portal Forms: Keep Branching Questions and Server Validation in Agreement

A portal asks whether a supplier is an individual or a company. Choosing company reveals registration fields; switching back hides them. The screen looks simple, but the submitted record may still contain the hidden company values. Another version of the form may require a field the current screen never displayed. Conditional questions become unreliable when visual branching and data rules evolve independently.

Treat the form as a small decision model. Define which answers activate each branch, which fields apply, what happens to values from a branch the user leaves, and how the server validates the final record. This creates a consistent contract for the interface, saved drafts, API clients, and reviewers who later need to understand the submission.

Write the branch rules in business language

Start with a table of conditions, visible fields, required fields, and explanations. For a supplier form, the condition might be organization type; for a service request, it might be whether site access is required. Avoid hiding important rules inside scattered interface callbacks. A product owner should be able to read the table and predict the questions a user will see for a given set of answers.

Give every branch a clear purpose. Do not request information just because another department might eventually find it useful. Explain why sensitive or unusual details are needed at the point of collection. Where a user genuinely does not know an answer, decide whether “unknown” is a valid state with a later review step. Forcing a guess can create a complete-looking form with unreliable data.

Distinguish visibility from applicability

A field can be hidden for layout reasons, inactive because its branch does not apply, or inaccessible because the user lacks permission. Those are different conditions. Define them separately in the data model and validation rules. A hidden control is not a security boundary, and a value in an inactive branch should not automatically influence approval, pricing, or document requirements.

OWASP’s input validation guidance distinguishes checking input structure from checking whether it is meaningful in the business context. Apply that distinction to branching forms: a registration number may have a valid format but still be inappropriate for an individual applicant. The server should evaluate the submitted branch and permitted values rather than trusting the interface to have asked the right questions.

Decide what happens when a branch changes

Choose deliberately between clearing inactive values, retaining them only in a draft, or preserving them as historical revisions. Each option has a cost. Clearing values avoids accidental submission but can frustrate someone who switches back. Retaining them improves recovery but needs a strong rule preventing inactive data from being treated as current. Show a concise warning when a change will discard meaningful work.

For a hypothetical equipment request, selecting “existing device” reveals an asset identifier, while “new device” asks for delivery details. If the user changes branches, the review screen should show only the applicable current answers. A saved draft may retain the previous branch locally for convenience, but the final submission should not combine an old asset identifier with a new-device purchase request unless the workflow explicitly allows that combination.

Make server validation authoritative and explainable

On submission, validate the controlling answers first, derive the active branch, and then validate the fields relevant to it. Reject or deliberately ignore disallowed fields according to a documented API contract. Do not accept a client-supplied flag claiming that a required section was completed. Recheck permissions for referenced records, uploads, and selected organizations as part of the operation.

Return errors that the interface can map to both a field and its controlling section. If an answer makes a previously optional field required, explain that relationship. Preserve the user’s draft when the server rejects it. An error saying only “invalid request” leaves the person unable to recover, while a message pointing to a currently hidden field suggests that the client and server rules have drifted.

Version rules for drafts and submitted records

Forms often change while users have unfinished drafts. Record the form or rule version associated with a draft and decide how older drafts move to the current version. A small wording change may need no special handling; a new required document may require an explicit review step. Show what changed and which answers need attention instead of silently invalidating an otherwise complete draft.

Keep a submitted record’s original meaning recoverable. Store the version used and enough information to explain which branch applied at submission. Later changes to the live form should not make historical records appear incomplete under rules that did not exist at the time. If a business process requires resubmission, create a deliberate new revision linked to the original rather than rewriting the old submission invisibly.

Keep dynamic questions accessible

Place newly revealed questions near the answer that activates them and preserve a logical reading and focus order. Do not unexpectedly move focus into a new section while someone is still choosing an option. Make required status and explanatory text available to assistive technology. Review how a screen reader user learns that the form changed without receiving repeated announcements for every keystroke.

Test keyboard navigation through each branch, including switching back after entering data. Hidden controls should not remain in the tab sequence. Error summaries should lead to visible, actionable fields. On small screens, keep the controlling answer understandable when its dependent section grows. A long form should not require the user to remember an earlier choice merely to interpret why a question is being asked.

Use AI to assist explanation, not decide eligibility

AI can help turn a complex rule table into draft help text or identify confusing questions during review. Check that its explanation matches the actual rules. Do not let generated prose become the only specification for required fields or eligibility. If AI extracts answers from an uploaded document, show the source and require review where the value determines a branch or consequential action.

Build a compact test matrix from the decision table. Cover each branch, each boundary condition, switching branches, missing controlling answers, extra inactive fields, and an older draft. Add direct API requests that bypass the visible form. Verify the final stored record and review screen, not only which controls appear. Keep these tests focused on meaningful rule combinations rather than duplicating every cosmetic interface detail.

Conclusion

Conditional forms work when the questions, stored values, and server rules describe the same decision. Define branches explicitly, handle inactive data deliberately, preserve rule versions, and make dynamic changes understandable. Review the final submission as well as the screen. A shared decision table gives the team a practical way to evolve the portal without surprising users or leaving reviewers to interpret contradictory records.