Gravity Forms conditional logic, from three real client forms.

The short answer

Gravity Forms conditional logic shows or hides a field based on earlier answers, and can also decide which confirmation a visitor sees and which notification gets sent. Each field’s rules match on all or any of the conditions you set.

The forms that work best follow one pattern: a single opening question in the customer’s own words, short branches that appear only when they apply, plain stored values behind every choice, and a test of every path before launch. Hidden fields are not saved, so nothing irrelevant clutters the entry.

How Gravity Forms conditional logic works

There are three places to use it, and they behave differently.

• Fields. In the form editor, open a field’s settings, find the Conditional Logic section and switch on Enable Conditional Logic. Choose whether the field shows or hides, and whether all or any of your rules must match. Each rule compares another field with a value, using operators such as is, is not, greater than or contains. A field cannot depend on its own value.
• Confirmations. The default confirmation has no logic. Add extra confirmations with conditions instead. If several match, only the first one runs, and the default runs only when none do.
• Notifications. A notification can have its own conditions, so it is sent only for certain answers. Notifications also offer routing, which picks the recipient by field value. Routing cannot stop a notification from sending, so every possible answer needs a rule.

Two limits matter when you design, and the same field documentation lists both. Fields hidden by conditional logic are ignored on submission and not saved in the entry. And nested conditional logic is not supported, so a rule cannot combine all and any in one condition set. The examples below work within both.

Example 1: an RV park reservation inquiry

Lakeside Oasis RV Park has 51 sites above Lake Cumberland in Albany, Kentucky, and guests contact it for very different reasons: a weekend, a season, a question about rates. The Reserve a Site form handles all of them with one opening question and short branches.

The opening question

A required radio button asking how the park can help, with five choices: book a nightly stay, reserve a site, check availability and rates, ask about a monthly, seasonal or yearly stay, or something else. Every choice has a short plain value behind it (nightly, reserve, rates, longterm, other), and every rule below uses those values.

The branches, exactly as built

• How long are you staying? appears only for reserve a site or check availability and rates. Its choices run from a night or two to the whole year, plus not sure yet.
• Arrival date appears for a nightly stay, or when the guest picks a night or two, a week or more, or not sure yet.
• Departure date uses the same rule minus not sure yet. A guest who is unsure about the length of the stay can still give a start date without being forced to invent an end.
• When would you like to start? replaces the dates for a month, a season or a year, or when the guest chose the long-stay question at the top.
• What are you bringing? appears for every choice except something else, and Approximate length appears only once a real rig type is picked.
• Preferred site number appears only for a nightly stay or a reservation, and Bringing a pet? for those plus long stays.

Every rule is a single list using any. No rule needs all, so nothing would need nesting. A Cloudflare Turnstile field sits last, before the button.

Pre-filling the form from a link

The park’s interactive map lets a guest pick a site, then carries that choice into the form. Selecting site 540 opens the contact page with the site number and the reason already filled in, through a link ending in ?site=540&help=reserve.

That uses Gravity Forms dynamic population:

1. On the field’s Advanced tab, tick Allow field to be populated dynamically.
2. Enter a parameter name, such as site for the site number field and help for the opening question. Parameter names are case sensitive.
3. Link to the form page with that parameter and value in the address.

For a choice field, the value in the link has to match the choice exactly, which is one more reason to give every choice a short plain value. Because the opening question arrives already answered, its branches open as the page loads, and the guest starts halfway through a form that already knows what they want.

Example 2: a plumber’s service request

Allied Plumbing in Bardstown gets a different question on every call, so its request form starts with the problem in the customer’s words: drain is slow or clogged, water heater problem or replacement, sewer or septic issue, and so on.

Pick a service and only its follow-ups appear. A water heater asks tank or tankless, gas or electric, what it is doing and roughly how old it is, with a note that a photo of the label beats a guess. A drain asks which drain, whether it has happened before and whether anyone used a chemical cleaner, which changes how the crew works safely. Nine service paths each carry their own questions, yet only three fields are required on any of them: a name, a number and a town or ZIP.

The same site keeps job applications on a separate conditional form, so recruiting traffic never mixes with customer requests. The thinking behind it is in my guide to what a service-business website should ask before the first call.

Example 3: a project inquiry with nine paths

My own contact form covers everything I do, from new websites to aerial photography, so it uses a few patterns the simpler forms do not need.

• An optional opening question. What do you need is not required. Someone who just wants to talk can skip it and still send a message.
• Shared questions on an is not empty rule. The project name and current website fields appear once any choice is made. One rule, is not empty, saves repeating them in every branch.
• One branch per service. A redesign asks what is holding the current site back. An online store asks roughly how many products and where they sell today. A rescue asks what is happening and whether the site is down right now.
• A second level. Choosing SEO or Google Ads asks which one. The ad budget question appears only for Google Ads or both, and the Google Business Profile question only for SEO, both or not sure.
• Exclusions with all and is not. The timeline question uses all: the main question is not empty and is not a rescue, because a broken site already has its timeline. The budget question adds a third rule to skip the advertising branch, which asks about ad spend on its own.

That last pattern is the workaround for no nesting: when you need an and, put every condition in one all list, and when you need an or, use any.

Rules I follow when building conditional forms

• Give every choice a plain value. Gravity Forms’ own documentation warns that labels with special characters can stop conditional logic, dynamic population and validation from working as expected, and recommends turning on show values. A plain value also means you can reword a label later without breaking a rule.
• Put the trigger first. Branches should open below the question that controls them, never above it.
• Require only what you truly need. A required field inside a branch is only enforced when the branch is showing, because hidden fields are ignored. Keep the always-required list short.
• Write rules as lists. Several conditions joined by any are easier to read and maintain than a stack of separate fields doing similar jobs.
• Re-save routing after editing choices. Gravity Forms notes that routing rules store choice values as they were when saved, so changing a dropdown’s choices means updating the routing rules too.
• Keep the anti-spam check last. A Turnstile field just before the button, with its space left visible. My notes on the blank gap above the Gravity Forms button explain why.

Test every path before launch

A conditional form has as many forms inside it as it has paths, and each needs a test.

1. Write the paths down. For the RV park form that is every opening choice, then every stay length under the branches that ask it.
2. Walk each one in the browser, checking that the right fields appear and the wrong ones stay hidden, on a phone as well as a desk.
3. Test the notifications on the server. Turnstile refuses automated browsers by design, so send clearly labeled test entries through the Gravity Forms API to check emails and routing.
4. Send one real entry from your phone, logged out, and confirm it arrives where it should.

Then keep testing after updates. A form is part of the site that quietly earns money, and it deserves the same checks as a checkout. If yours is getting junk instead of inquiries, see contact form spam: the fix that actually works.

Frequently asked questions

Can one field depend on two different questions?

Yes. Add a rule for each question and choose all if both must match, or any if either will do. The RV park’s arrival date field, for example, checks the opening question and the length of stay in one any list.

Can I combine and and or in the same rule?

Not in one condition set, because nested conditional logic is not supported. Put every condition that must be true into one all list, use any for alternatives, and if you truly need both, split the field into two fields with their own rules.

Are hidden fields saved with the entry?

No. Fields hidden by conditional logic are ignored on submission and not saved, so the entry only contains what the visitor actually saw and answered.

Can conditional logic send different emails for different answers?

Yes. Give each notification its own conditional logic, or use routing to send one notification to different people depending on an answer. Routing always sends, so make sure every possible answer has a rule.

Can a link pre-select an answer?

Yes, with dynamic population. Allow the field to be populated dynamically, give it a parameter name, and add that parameter to the link. The branches that depend on it open as the form loads.