Most forms ask everyone the same questions, even when those questions don't apply. A prospect who runs a 500-person SaaS company doesn't need the same intake flow as a solo freelancer. When everyone sees every field, completion rates drop, lead quality suffers, and your sales team wastes time chasing the wrong conversations.
Conditional logic solves this. The ability to show or hide form fields based on a respondent's previous answers turns a static form into a dynamic, personalized experience that feels less like a survey and more like a conversation. The result: higher completion rates, cleaner data, and leads that are pre-qualified before they ever reach your CRM.
In this guide, you'll learn exactly how to set up conditional logic in your forms, step by step. We'll cover how to map your logic before you build, how to configure show/hide rules, how to handle multi-branch paths with AND/OR operators, and how to test everything before going live. Whether you're building a lead qualification form, a product intake survey, or a multi-step onboarding flow, these steps will give you a repeatable process for creating forms that adapt to each respondent in real time.
Step 1: Map Your Logic Before You Build Anything
Here's the most common mistake teams make with conditional logic: they open their form builder and start wiring up rules on the fly. Twenty minutes later, they have a tangled web of conditions that contradict each other, fields that show when they shouldn't, and no clear way to debug what went wrong.
The fix is simple. Before you touch your form builder, map your logic on paper or in a lightweight tool like Whimsical, Miro, or even a basic flowchart in Figma. You're building a decision tree that shows every possible path a respondent can take through your form.
Start by identifying two types of fields:
Trigger fields: These are the questions whose answers control what happens next. "What best describes your role?" or "What is your company size?" are classic trigger fields. The respondent's answer determines which fields appear or disappear.
Dependent fields: These are the fields that show or hide based on trigger answers. A "What's your annual software budget?" field might only appear when a respondent identifies as a Decision Maker. That makes it a dependent field.
For each branching point in your flowchart, write out the logic explicitly: "If the answer to Question 3 is 'Enterprise', show fields 4a, 5a, and 6a. If the answer is 'SMB', show fields 4b and 5b instead." This level of specificity feels tedious before you start, but it saves significant debugging time later.
One important constraint to build into your planning: keep branches to a maximum of three or four levels deep. Beyond that, logic conflicts become increasingly likely, and the respondent experience starts to feel maze-like rather than conversational. If your flowchart is going deeper than four levels, look for opportunities to consolidate questions or split the form into multiple forms.
The success indicator for this step is straightforward: you should be able to trace every possible path from start to finish without any ambiguity, and you should be able to do it before you open your form builder. If you can't trace a path cleanly on your flowchart, you won't be able to build it cleanly in your tool either.
Step 2: Set Up Your Trigger Fields First
With your logic map in hand, it's time to open your form builder. The first rule here is sequencing: always add your trigger fields before you add your dependent fields. Most form builders reference trigger fields by name when you're configuring conditional rules, so if the trigger field doesn't exist yet, you can't build the rule that depends on it.
Field type selection matters more here than anywhere else in your form. For trigger fields, you want discrete, predictable values. That means:
Dropdown menus: Ideal for trigger fields with four or more options. They keep the interface clean and produce consistent values that your conditional rules can reliably match.
Radio buttons: Best for two to four options where you want all choices visible at once. Like dropdowns, they produce exact, consistent values.
Checkboxes: Useful when respondents can select multiple answers, but require more careful logic configuration since multiple values can be selected simultaneously.
What you want to avoid as trigger fields: open text inputs. If a respondent types "freelancer" instead of "Freelancer" or "free lancer", your conditional rule that looks for "Freelancer" will fail silently. The field won't show, and you won't know why. Free-text triggers introduce variability that breaks logic rules in ways that are genuinely hard to catch.
Once you've chosen your field types, label your options carefully. The exact text of each option is what your conditional rules will reference. If you later rename "Small Business" to "SMB", every rule that references "Small Business" will break. Finalize your option labels before you write a single conditional rule.
In Orbit AI's form builder, trigger fields are added through the standard field panel on the left side of the editor. Once a field is added to your form, it automatically becomes available as a condition source in the logic editor. You'll see it appear in the trigger field dropdown when you're configuring rules for dependent fields.
The success indicator for this step: all trigger fields are in place, their options are finalized and exactly as they'll appear in the live form, and you haven't started adding dependent fields yet. That last part matters. Resist the urge to add everything at once.
Step 3: Add Dependent Fields and Configure Show/Hide Rules
Now add your dependent fields to the form. At this stage, add all of them, even though most will be hidden from respondents most of the time. Think of it like laying out all the puzzle pieces before you start assembling them.
Before you write a single rule, confirm one critical setting: the default visibility state of each dependent field. In most modern form builders, you want conditional fields set to hidden by default. This means the field is invisible until a specific condition makes it appear.
The alternative, "visible by default, hide on condition," creates a poor experience. Respondents briefly see a field appear and then watch it disappear as the form loads or as they answer previous questions. That flickering creates confusion and erodes trust in the form. Always default to hidden, then reveal.
With default visibility confirmed, open the logic or conditions panel for your first dependent field. The basic rule structure looks like this:
"Show this field IF [trigger field] equals [specific answer]"
In Orbit AI, navigate to the field settings for your dependent field, select "Conditional Logic," choose your trigger field from the dropdown, select your operator, and enter the trigger value. The operators available typically include: equals, does not equal, contains, does not contain, is empty, and is not empty.
That "is not empty" operator is worth highlighting. Use it when you want a follow-up field to appear as soon as any answer is given to a previous field, regardless of what that answer is. For example, if you ask "What's your biggest challenge right now?" and you want a follow-up "Tell us more" field to appear after any response, "is not empty" handles that cleanly without requiring you to list every possible answer.
For hide logic, the pattern reverses. If you want to show a field to most respondents but hide it for a specific subset, set the rule to: "Hide this field IF [trigger field] equals [specific answer]." This is less common than show logic, but useful when a field is relevant to the majority and you only need to suppress it for a particular segment.
One pitfall to watch carefully: applying logic to the wrong field. When you have many dependent fields open in your builder, it's easy to configure a rule while the wrong field is selected in the logic panel. Before saving any rule, double-check the field name displayed at the top of the logic panel and confirm it matches the field you intend to configure.
The success indicator: every dependent field has at least one active condition rule, and the default visibility is set to hidden for all of them.
Step 4: Build Multi-Branch Paths with AND/OR Logic
Single-condition rules handle straightforward branching. But real lead qualification forms often need more nuance. This is where AND/OR logic comes in, and where most builders start making errors.
Here's the mental model to lock in before you build anything:
OR logic: The field appears if any of the conditions are true. Use this when multiple different answers should trigger the same dependent field. For example, show a "Tell us about your team structure" field if the respondent selects "VP of Sales" OR "Head of Revenue" OR "CRO."
AND logic: The field appears only when all conditions are true simultaneously. Use this when a field is only relevant to a very specific combination of answers. For example, show a "What's your annual software budget?" field only if the respondent selects "Decision Maker" AND "Company size is 50 or more employees."
The most common logic error is mixing AND and OR conditions on the same field without a clear mental model. Before you configure any multi-condition rule, write out the logic in plain English first: "This field should appear when X AND Y are both true" or "This field should appear when X OR Y is true." If you can't write it in plain English, you're not ready to configure it in your builder.
Orbit AI's logic editor supports both AND and OR operators within a single rule set. You can chain multiple conditions together and choose the operator that governs how they interact. This lets you build nuanced qualification paths without needing workarounds or duplicate fields.
For complex multi-branch forms, consider using page breaks or sections to group related conditional fields together. This has two benefits: it makes the builder easier to navigate when you're configuring rules, and it creates a cleaner experience for respondents who only see the fields relevant to their path.
A practical example of multi-branch logic in a lead qualification context: you might show a "Preferred implementation timeline" field only if the respondent selects "Decision Maker" AND "Company size is 10 or more." This ensures that detailed procurement questions only reach the respondents who are positioned to act on them, while keeping the form streamlined for everyone else.
Return to your Step 1 flowchart here. Every branch you drew should now have a corresponding set of rules in your builder. Work through the flowchart systematically, checking off each branch as you configure it. The success indicator: no branch in your original flowchart is unaccounted for in your rule set.
Step 5: Test Every Path Before Publishing
Testing is where most teams cut corners, and it's where broken forms slip through to production. The "happy path" trap is real: you test the most common respondent journey, everything looks fine, and you publish. Then a week later you discover that a specific combination of answers breaks the form for a segment of respondents who happen to be your highest-value leads.
The antidote is systematic testing. Go back to your Step 1 flowchart and create a testing checklist directly from it. List every branch and every path. Check them off one by one as you verify each one works correctly in preview mode.
In Orbit AI, use the built-in preview with test mode enabled. This lets you simulate submissions and verify that conditional data is captured correctly in the responses panel, not just that the fields appear and disappear visually on screen.
Beyond the standard paths, test these specific edge cases:
Answer changes: What happens when a respondent selects an answer that reveals a set of dependent fields, then goes back and changes their answer? Do the previously revealed fields hide correctly, or do they get stuck in a visible state? This is a common rendering issue that only surfaces through deliberate testing.
Field ordering: When a hidden field becomes visible, does it appear in the correct position within the form flow? Fields that jump to unexpected positions create a disorienting experience.
Empty submissions: Try submitting the form with a trigger field left blank (if the field is optional). Do dependent fields behave correctly when the trigger has no value?
Mobile rendering: Conditional logic rendering can behave differently on smaller screens. Always verify your form on at least one mobile device or a browser emulator set to a mobile viewport. Pay particular attention to fields that appear dynamically: do they render in the right position, and is the form scrollable to reach them?
Document every test you run and its result. If a path fails, fix the rule, then re-test that path and all adjacent paths to confirm the fix didn't introduce a new issue elsewhere.
The success indicator: every branch from your flowchart has been manually tested, produces the correct field visibility, captures the correct data, and renders correctly on both desktop and mobile.
Step 6: Connect Conditional Data to Your CRM and Workflows
A conditional form that captures nuanced lead data is only as valuable as what you do with that data downstream. This final step is where your form's intelligence gets translated into action.
Start with a technical consideration that catches many teams off guard: conditional fields that were never shown to a respondent will typically pass as empty or null values in your form submission payload. Before connecting your form to a CRM or automation tool, confirm that your downstream system handles null values gracefully. Some integrations exclude empty fields from the payload entirely, which can cause data mapping issues or trigger errors in your automation sequences.
Once you've confirmed null handling, map each conditional field to the correct CRM property. This is where the lead qualification data your form collected, company size, role, budget range, use case, gets structured and segmented automatically. If this mapping is done correctly, your sales team sees a fully profiled lead in their CRM without any manual data entry.
The real power of conditional form data is in automation triggering. Different paths through your form should trigger different downstream sequences. A respondent who selects "Enterprise" and "Decision Maker" might trigger a high-priority sales alert and a personalized outreach sequence. A respondent who selects "SMB" and "Just exploring" might route to a nurture sequence with educational content. The conditional logic in your form extends into your post-submission follow-up.
Orbit AI's workflow and sequences features are built for exactly this. You can create branching automation directly from form response data, so the qualification logic you built in your form continues to work after the respondent hits submit.
If you're using third-party automation tools like Zapier, Make, or a direct CRM integration, verify that conditional field data is included in the webhook or API payload. Test this by submitting a test entry through each branch of your form and checking the raw payload in your automation tool's log. Confirm the correct fields are present and the correct values are passed.
The success indicator: a test submission through each branch produces the correct data in your CRM and triggers the correct automation sequence for that respondent profile. Every path through your form has a corresponding downstream action.
Your Pre-Publish Checklist
Conditional logic transforms a generic form into a precision lead qualification tool. When you map your logic first, configure trigger and dependent fields carefully, handle multi-branch paths with AND/OR rules, test every possible path, and connect your data to downstream workflows, you end up with a form that works harder than any static alternative.
Before you hit publish, run through this checklist:
Logic mapped before building: Your decision tree is documented in a flowchart, and every path is traceable from start to finish.
Trigger fields use discrete types: All trigger fields use dropdowns, radio buttons, or checkboxes, not free-text inputs.
Dependent fields default to hidden: No conditional field is visible by default before its trigger condition is met.
Every branch has a corresponding rule: Your flowchart and your rule set match exactly, with no unaccounted paths.
AND/OR logic is applied correctly: Multi-condition rules are written out in plain English before being configured in the builder.
Every path has been manually tested: Including edge cases like answer changes, empty submissions, and field ordering.
Mobile rendering is verified: The form behaves correctly on at least one mobile viewport.
Conditional data flows correctly downstream: Test submissions through each branch confirm correct CRM data and correct automation triggers.
If you're looking for a form builder that makes all of this straightforward, with a visual logic editor, built-in lead qualification, and native workflow automation, Orbit AI is built for exactly this use case. Start building free forms today and see how intelligent form design can elevate your conversion strategy.
