A form grows by addition. Someone needs one more field for the freelancers, someone else needs two more for the applicants who already work there, and within a year the form asks everybody everything. The completion rate falls, the answers get thinner, and the team handling the responses starts skipping past the fields that are blank most of the time.
Conditional logic is the fix, and it is a fix with its own failure modes. Setting up a branch takes two minutes. Testing every path through the form afterwards takes considerably longer, and forms are usually shipped without that step, which is why so many conditional forms have a state a respondent can reach and cannot get out of.
Three units a form can branch on
Every tool in this category does at least one of these, and they are not interchangeable.
Field level. A single question appears or disappears based on an earlier answer. Tick the box marked "Invoice required" and a company name field appears underneath it. This is the finest grained option and the one people usually picture.
Section or page level. A whole block of questions is skipped. The respondent answers the qualifying question, presses next, and lands on a different page depending on what they chose. Coarser, but often better structured, because a section carries a heading that tells the respondent where they are.
Ending level. Different respondents reach a different final screen. Somebody who does not qualify gets told so and gets a link to something else, instead of filling in six more fields and then being rejected by email. Typeform lists multiple endings per form as a feature, and the same effect is available anywhere a branch can terminate the form.
Plain HTML has none of this built in. A form written by hand can hide and show fields, but only with JavaScript, which means the hidden fields are still in the page and still need checking on the server. Every hosted form tool provides it as a setting instead, and what varies is which of the three units it operates on and what it is allowed to look at.
Where to put the branch
The single most common mistake is putting the qualifying question too late.
The question that decides which path a respondent takes belongs near the top, before anything expensive. If the form asks for a portfolio URL, three dates of availability and a written statement, and only then asks whether the applicant is based in a country the role allows, the respondent has already spent ten minutes and the team has already collected data it will never use.
Put the deciding questions first, in this order: eligibility, then category, then detail. Eligibility questions send people who do not qualify to an ending. Category questions choose which set of detail questions follows. Detail questions are last and are never branch conditions themselves, because branching on a free text answer is fragile even in tools that allow it.
One refinement worth the effort: make the qualifying question feel like part of the form rather than a gate. "Which of these describes you best" reads better than "Are you eligible", and it produces the same branch with a better completion rate.
Keep the number of paths countable
Two independent yes or no branches produce four paths. Three produce eight. At eight paths nobody tests them all, and the untested ones are where a required field sits inside a hidden section and silently blocks submission.
A practical ceiling is one branch axis with up to four options, plus at most one secondary branch inside a single arm of it. If the form needs more than that, it is usually two forms wearing one coat, and splitting it is cheaper than maintaining the logic.
What each tool can branch on
The differences here are larger than the pricing differences, and they are the ones that force a form to be restructured after it has been built.
| Tool | Unit it branches on | What it can look at | Notes |
|---|---|---|---|
| Google Forms | Section | Multiple choice and Dropdown answers only | Can also end the form on an answer |
| Typeform | Question, and endings | Answers, hidden fields, variables and scores | Conditional logic included on Basic, 39 USD per month |
| Tally | Question and page | Answers, with calculations | Conditional logic and calculations listed on the free tier |
| Jotform | Field and page | Field values, with calculations | Available on the free Starter plan |
| Cognito Forms | Field and section | Field values, with calculations | Available on the free Individual plan |
| WPForms | Field | Field values | Listed as Smart Conditional Logic |
Google Forms is the one to check carefully, because it is the tool most forms start in. Its branching setting is called "Go to section based on answer", and Google's own documentation states that it is available only for Multiple choice and Dropdown question types. Nothing can branch on a text answer, a number, a date or a checkbox grid. The unit skipped is a whole section, added with "Add section", and the destination is chosen at the bottom of each section. It works, and it means the form has to be organised into sections that match the branches rather than the other way round.
Anything involving a calculation, such as showing a follow up question only when a rating is below a threshold, needs a tool that supports numeric conditions. Several do it for free.
Piping answers forward is the other half of the same setting
Conditional logic decides what a respondent sees. Piping decides how it is worded, and the two together are what make a long form feel short.
The feature has different names. Typeform calls it recalling information, described on its own pricing page as pulling data from previous questions to show respondents later. Tally lists answer piping among the features on its free tier. The effect is the same: a question that has already been answered gets reused in the wording of a later one, so an applicant who typed a project name sees that project name in the questions that follow instead of a generic label.
Two uses justify the setup time. The first is confirmation, where a summary screen before submission repeats what was entered, which catches typed email addresses that are wrong by one character. The second is specificity, where a follow up question names the thing being asked about rather than saying "the above", which produces noticeably longer written answers.
Prefilling works in the opposite direction. A link that carries values in its query string can arrive with fields already populated, which is how a reminder sent to a known contact avoids asking for a name and an email address that are already on file. Hidden fields hold that data without showing it, and several tools allow branching on hidden field values as well as on visible answers.
Four failures that show up in conditional forms
A required field inside a hidden branch. The field is hidden, so nobody can fill it in, and the form refuses to submit without explaining why. Most tools exempt hidden fields from validation, but not all of them, and the ones that do sometimes stop exempting them when the field is hidden by a second level condition. Test by taking every path to submission.
The orphan branch. A section that nothing routes to, usually left behind after a question was reworded. It never appears, so it is never noticed, until someone edits the form and accidentally sends half the respondents into it.
Contradictory conditions on one field. Two rules point at the same question, one showing it and one hiding it. What happens is tool specific and rarely documented. Keep one rule per field and express complex cases as a single condition with several clauses.
The unreachable ending. A rejection ending that no path arrives at, so people who should have been told early instead complete the whole form. This is worth checking explicitly because it fails silently and the cost lands on the respondent.
The test that catches all four takes about fifteen minutes: list every path, walk each one to the end in a real submission, and confirm what arrives on the response side matches the path that was taken.
Conditional logic changes the data that comes out
A conditional form produces a sparse export. Every possible question is a column, and each row only fills in the columns on the path that respondent took. Fifty responses across four branches produce a spreadsheet with a lot of white space, and totals or averages across the whole set stop meaning anything because the denominators differ per column.
Three habits make that manageable. Keep the questions that everybody answers together at the front, so the comparable columns sit side by side. Record the branch itself as an answer rather than leaving it implied, so each row says which path it took. And put anything the team decides afterwards, such as an outcome or a next step, in a separate field on the response rather than in a spreadsheet column, so it stays attached to the record when the data is exported again.
The last of those three is the one that keeps getting rebuilt by hand. A conditional form makes the incoming data cleaner, and it does nothing at all about the part of the process that starts once the response exists. Whether each response has an owner, what stage it has reached and what was sent back to the person are all still open questions, and the answers tend to live in whatever the team set up for themselves rather than in the form tool.
Where conditional logic stops helping
Branching decides which questions a respondent sees. It does not decide who deals with the result, and those two get conflated often enough to be worth separating.
Routing by content is a different feature with a different name. Sending applications from one category to one colleague and another category elsewhere is notification routing, or ownership, or stage assignment depending on the tool, and plenty of builders with excellent conditional logic have nothing for it beyond sending every submission to the same address. The form gets shorter for the respondent and the handling stays exactly as manual as it was.
Worth checking against any tool you are considering: can a response be assigned to a person, can it carry a status that everyone sees, and is the reply that was sent stored on the response itself. Those three are independent of how good the branching is, and they are what the difference in day to day work actually rests on.
What to change first
Move the qualifying question to the top of the form, before anything that takes effort to answer, and send the people it excludes to an ending rather than through the rest of the form. Then count the paths, and if there are more than four, split the form instead of adding logic. Once that is done, check whether the responses arriving from those branches get an owner and a status automatically, and if they do not, see what that looks like in Halict or any tool built the same way.
Q1. Can Google Forms show a question based on a text answer?
No. Google documents "Go to section based on answer" as available only for Multiple choice and Dropdown question types, and the unit it skips is a whole section rather than a single question. Branching on a text answer, a number or a date needs a different tool.
Q2. Does conditional logic improve completion rates?
It helps when it removes questions the respondent would otherwise have had to read and skip, and it hurts when the branching makes the form feel unpredictable or when a hidden required field blocks submission. The reliable gain comes from asking fewer questions per person, not from the logic itself.
Q3. Is conditional logic a paid feature?
Not always. Tally lists conditional logic and calculations among the features on its free tier, and Jotform and Cognito Forms both include conditions on their free plans. Typeform includes it on Basic at 39 USD per month, and Google Forms includes section branching at no cost within the limits described above.
Q4. What happens to hidden fields when the form is submitted?
In most tools a field hidden by a condition is not validated and is submitted empty, so it appears as a blank column in the export. This behaviour is not universal, which is why a required field inside a hidden branch is the most common bug in conditional forms. Take every path to submission once before launching.
Q5. Should a long form use conditional logic or be split into several forms?
Count the paths. One branch axis with a handful of options belongs in a single form, because the respondent answers one extra question and sees a shorter form. Once there are more than four or five distinct routes, separate forms are easier to maintain, easier to test and easier to read in an export, even though they need their own links.