Conditional logic in forms: rules, examples and a proof test

What conditional logic means

Conditional logic changes a form or its next action when a stated condition is true. It can show or hide questions, skip pages, select an outcome, calculate a value or choose a post-submit workflow action.

A conditional rule has five parts: an input, an operator, a comparison value, an action and a fallback. “If company size is 500 or more, show the enterprise questions; otherwise continue to the standard next step” is complete. “Use logic for enterprise leads” is not.

Five common rule patterns

Give every pattern an explicit fallback. The fallback can continue to a standard path, show a review message or record an exception, but it should never depend on whichever overlapping rule happens to execute first.

Current product examples

As verified September 16, 2026, Tally documents show-or-hide blocks, page jumps, calculated values, required-field changes, redirects and custom thank-you pages. Its rule builder supports all-or-any condition groups, and its documentation warns that complex logic can be error-prone and should be tested through different scenarios.

Jotform's conditional-logic guide, updated August 27, 2026, documents show-or-hide, calculation, require-or-mask, page skipping, thank-you changes and conditional email recipients. It likewise recommends testing an existing rule before adding more conditions.

These examples demonstrate current rule categories, not a product winner. Exact operators, nesting, plan access and workflow actions can differ by workspace and change after the verification date.

Truth-table method

Write every meaningful input combination before opening the form builder. For an enterprise branch requiring both company size of at least 500 and a start window within 90 days, the core table has four rows:

Add rows for blank, malformed, unsupported and exact-threshold values. For every row, name the expected page, visible and required fields, result, stored values and post-submit action. This converts a visual branch into a specification another reviewer can reproduce.

Worked conditional-logic example

A training enquiry asks country, team size and start window. Unsupported countries reach a resource page. Supported contacts with at least 500 employees and a near-term start see enterprise implementation questions. Other supported contacts take a shorter standard path. Every route still collects the promised delivery field and ends in a valid result.

The enterprise condition can then feed the separate lead-qualification model. Keep branch logic and lead ownership distinct: showing enterprise questions does not by itself assign an accountable sales owner or prove that the respondent is qualified.

Nine-case branch proof test

Run these cases with synthetic records before publishing:

1. both enterprise conditions are true;
2. only company size is true;
3. only the start window is true;
4. neither condition is true;
5. a required trigger is blank or unsupported;
6. a value is exactly at the 500-person or 90-day boundary;
7. an earlier answer changes after the conditional path appears;
8. the respondent navigates back or attempts to open a later step directly; and
9. client-side validation is bypassed or an unexpected value reaches the server.

For each case, confirm the visible questions, required state, calculation, result, stored data and workflow action. The test fails if a hidden field remains required, two outcomes tie silently, a changed answer leaves stale data active or an unsupported value reaches an undefined route.

Accessibility and safety checks

When fields appear, keyboard focus should remain predictable and the instructions should still make sense in reading order. The W3C form-validation tutorial recommends concise, easy-to-understand error feedback associated with the relevant control; WCAG's error-identification guidance requires detected input errors to be identified and described in text.

Validate consequential rules on the server as well as the client. A hidden field must not remain required, and a skipped page should not leave sensitive data active without a defined retention or clearing rule. Test the final form on representative devices, with a keyboard and assistive technology, and through the actual integration path.

This framework does not claim a conversion lift. Logic terminology, plan gates, operator support and calculation behavior differ by platform. Recheck the chosen product and repeat the documented test method in the intended workspace.

Evidence and limitations