Jotform conditional logic: show fields, route and calculate

Write the rule in plain language first. State the trigger, the result and the default path. Then build that rule using the current Jotform rules help.

Choose the Jotform conditional logic type

Start with what should change for the user. A follow-up question may need to appear only for a certain service. A total may need a supported calculation. A result may need a distinct ending or recipient under the documented workflow.

Do not use a calculation as a hidden substitute for a payment check. Do not use a visible field change as proof that staff received the correct notice. The field, the stored response and the receiving route are distinct layers.

Prepare an example inquiry form

This is an illustrative form, not a user case study. A fictional service business asks for a request type with three choices: “repair,” “installation” and “not sure.” A repair request needs a short description of the issue. An installation request needs the proposed location or scope. An uncertain user needs a general description field.

Keep reply details short. Ask for a contact address when the user wants a reply and explain its job. Avoid collecting unrelated profile data just because the form can show more fields.

Create the rule

Open the form's current rules settings in the Jotform builder. Select the supported action matching the task. Choose the source question, the comparison and the resulting field or behavior. Control labels can change, so follow the current vendor guide for the exact screen.

Add one rule at a time. Use clear field names so a later editor can understand it. Keep a written description beside the form's operating record: “When request type is repair, show repair details.”

Preview the normal path before adding another rule. A small verified branch is easier to reason about than several overlapping rules built at once. Avoid copying a condition from another form without checking its field references.

Check blank and conflicting answers in Jotform conditional logic

Leave the trigger question blank where the form allows it. The result should follow a deliberate default. If the question is required, its error should explain what the user needs to answer without exposing an unreachable field.

Choose one branch, enter detail and then change to another branch. Inspect the visible form and the resulting stored response through the vendor's supported test route. Do not assume the old hidden value is removed or retained without checking.

Create a case where two rules could apply. Decide whether they should agree, have a documented order or be rewritten to avoid the conflict. An unclear priority can produce a form that looks correct in one path and fails in another.

Validate hidden fields and destinations

A required field should not block submission when the user cannot reach it under the planned path. Check how the chosen condition and current form settings handle that state. Avoid telling users to fill an invisible field as a workaround.

Inspect the stored response, notice and final page separately. A visible branch does not prove the correct team received the request. If a routing condition changes the recipient, verify the real destination using fictional test details.

Keep an “other” or human-review route when a request does not fit. Unknown is a valid state for a new inquiry. Do not convert a missing answer into zero cost, an accepted service or a confirmed booking.

Calculations need their own acceptance cases

For a supported numeric calculation, define units and valid inputs. A blank quantity is not by itself zero. Check the field's documented numeric behavior and use clear validation where the business needs a value.

Test a small normal value, a boundary and a missing value. Keep any prices tied to a real current product source. A fictional example should be labelled so it is not mistaken for a live offer.

If a calculation feeds a payment, inspect the gateway result separately. The Jotform order-form guide keeps the form total and paid state distinct. A condition rule alone cannot prove a completed charge.

Maintain and remove rules

Recheck rules when a field name, choice or service changes. A rule can still exist while referring to an old business meaning. Keep the source question and planned outcome in the upkeep record.

Before removing a field, inspect any rule that uses it. Use a safe copy or the vendor's supported version route where available. Confirm the normal and default paths after the change.

If a form becomes hard to explain, simplify the task. Several forms with clear purposes may be better than one long intake with many exceptions, but compare the current form limits and staff workflow before splitting it.

When another form builder fits

For simple section routing, compare Jotform and Google Forms. For a question-led sequence, compare Typeform and Jotform. Choose by the needed branch and response process rather than the broad label “logic.”

Distinguish all-match and any-match rules

Jotform’s condition settings distinguish rules that require all listed comparisons from those where any comparison can trigger the action. For a fictional installation request, “service is installation AND access is restricted” should show the access question only when both facts apply. Using OR would also show it to an unrelated repair request with restricted access.

Write the four combinations before choosing the operator: both true, first only, second only and neither. Assign the expected field state for each. Then check a user who changes one answer after filling the revealed field. This small truth table exposes the rule’s meaning before you add more conditions. It is more informative than clicking the single happy path and assuming the remaining combinations are equivalent.

Continue with the right task

• form builder
• website widgets