- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
Done well it makes a long form feel short — done carelessly it produces a form that cannot be submitted and will not say why.
Show a field based on an answer: conditional fields that behave
Conditional fields let a form ask a follow-up only when it is relevant. Tick “I have a vehicle” and the registration field appears; choose “other” and a text box opens to explain. Done well it makes a long form feel short, because nobody sees the questions that do not apply to them.
It is a narrower tool than branching a whole step. Where skip logic across whole steps sends a respondent down a different path, a conditional field changes one question in place — and the failure modes are different enough to be worth separating.
What to make conditional
| Pattern | Example | Why it works |
|---|---|---|
| A detail only some people have | Registration number, shown when they said they have a vehicle | Nobody is asked for something they do not have |
| An explanation for “other” | A text box opening beside the option | Captures what the option list missed |
| A follow-up that depends on scale | Number of locations, when they said more than one | Keeps the common case to one question |
| Address detail by country | The right fields for the country selected | Formats differ enough that one shape fits nobody |
| A consent or preference that only applies sometimes | Shown when the earlier answer makes it relevant | Avoids asking for a permission that has no purpose |
The pattern in all five is that the conditional field is a genuine follow-up to something already answered. Where a field is shown for a reason the visitor cannot infer, it reads as the form behaving unpredictably.
The rules that keep it predictable
- Trigger on a choice, not on typed text. Conditions reading free text fail on spelling, spacing and case. Drive them from options, with the cautions in writing a dropdown option list — particularly that renaming an option label breaks every rule referencing it.
- Make hidden fields not required. A required field that is hidden will block submission with an error pointing at something invisible, and the visitor has no way to resolve it. This is the most common defect in conditional forms and the hardest to diagnose from a support message.
- Clear the value when the field hides. Otherwise an answer given, then made irrelevant by changing an earlier response, is still submitted — and the record contradicts itself.
- Keep the appearing field adjacent to its trigger. A field that opens further down the page is easy to miss entirely, especially where layout reorders as how a phone stacks your columns describes.
- Avoid conditions on conditions. Two levels are comprehensible; three produce a form that behaves differently depending on the order in which answers were changed.
The second point is worth restating because it has a matching failure on the other side: a validation rule that fires for a hidden field produces a form that cannot be submitted and gives no usable reason. The standard for the message when it does fire is in required-field validation.
Movement, and why it unsettles people
A field appearing pushes everything below it down. If the visitor was about to press the button, the button has moved, and on a phone that means a mistap or a moment of confusion. Two mitigations help: reserve the space where the layout allows, and put conditional fields above the action rather than immediately beside it.
Inside an embedded frame the same movement changes the required height, and a frame that does not grow clips whatever appeared — the mechanism behind why an embedded frame clips. Test the form with each condition triggered rather than only in its default state, since the default is the one state guaranteed to look correct.
Where the form is stepped, a field that appears can change how much is left, which is the honesty problem described in the progress bar element — and it is a reason to prefer conditional fields within a step over conditions that add steps, with the wider trade-offs in splitting a form across steps.
What the answers should do afterwards
A conditional field usually exists because the answer changes something: who handles the enquiry, which sequence runs, whether the person is a fit at all. Wire that explicitly rather than leaving it to whoever reads the record — the intake layer in routing and suppression — and where an answer means you cannot help, route it into the disqualify path rather than into the general queue.
Remember that conditional fields produce blanks by design. A blank now means “not asked” as often as it means “declined”, so record which conditions were met if the distinction will matter later. Analysis of a conditional form without that is guesswork.
Testing, and reuse
Walk every combination that a real person could produce, including the awkward ones: answer, reveal the field, fill it, change the earlier answer, and submit. That sequence is where cleared values and stale requirements show up, and it is the one nobody tests.
Then submit a real response for each path and read what arrived, rather than trusting the form’s own preview. And if the section is going into a shared library, verify the conditions survived the copy — logic is among the things most likely to arrive incomplete, which is the general caution in saving a section to a library. The last thing to confirm is the ending: that what the submit button should say still describes what happens, whichever fields the visitor ended up seeing.
Frequently Asked Questions
When should a form field be conditional?
When it is a genuine follow-up to something already answered — a detail only some people have, an explanation for an ‘other’ option, or fields that depend on a country or a scale. Where a field appears for a reason the visitor cannot infer, the form reads as unpredictable.
Why does a conditional form refuse to submit with no visible error?
Almost always because a hidden field is still marked required. The validation fires against something invisible, and the visitor has no way to resolve it. Make hidden fields not required, and clear their values when they hide.
Can a condition be driven by typed text?
It can, and it should not. Rules reading free text fail on spelling, spacing and capitalisation. Drive conditions from defined options, and remember that renaming an option label breaks every rule that referenced it.
What happens to an answer when its field is hidden again?
Unless the value is cleared, it is still submitted — so a record can contain an answer that contradicts the earlier response which made the question irrelevant. Clear values on hide.
Why does the layout jump when a field appears?
Because everything below it moves down, including the button the visitor may have been about to press. Reserve the space where the layout allows, keep conditional fields above the action, and check what happens inside an embedded frame, which may not grow to fit.
What should be tested on a conditional form?
Every combination a real person could produce, including changing an earlier answer after filling the revealed field. Then submit a real response down each path and read what arrived, rather than trusting the builder’s preview.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.