Every logic block has one or more rules. Each rule pairs a condition group (when should this fire?) with one or more actions (what should happen?). Nine action types are available:
A logic block is a document element — it sits on the canvas between questions, just like a heading or an image. You can place it anywhere: between two fields on the same page, at the top of a page, or right before a page break.
Conditions are the When side of a rule. Each condition picks a field, applies an{' '} operator, and often compares against a value. The field picker groups what you can watch:{' '} Questions, Hidden Fields, Calculated Fields, and Metadata (today, the respondent's locale).
Once a rule has two or more conditions, a toggle appears at the top of the When section:
Add a set of conditions nests a second group inside the first, one level deep, with its own All/Any toggle. That covers compound logic like "plan is Pro and (country is Norway or country is{' '} Sweden)". A set holds conditions only — it cannot hold another set.
> ⚠️ **A hidden question has no value** >> If logic hides a question, the answer it may already hold counts for nothing — not in conditions, not in calculations, not in the > payment amount, and not in the stored submission. The answer comes back only if the question becomes visible again. The same goes for > every question inside a hidden row, column or repeating group, and for a picked option that logic hides. A page that the Set next page > rules skip counts as hidden too: its questions are not required, and whatever was answered there is dropped. Hidden fields are > the opposite: they always carry their value. >
> 💡 **Keep it readable** >> If a single logic block feels too complex, consider splitting the logic across multiple logic blocks or restructuring your form pages. >
The operator list is decided by the field you picked — you only ever see the ones that field supports. Below, each heading names the exact set.
Every text comparison ignores letter case and spaces at either end, so x@Competitor.com ends with{' '}
@competitor.com.
The other text-like inputs carry a narrower set, so pick the type that matches how you need to compare:
Schedule appointment and Documents can be visibility targets but never condition sources. A booking is attached to the submission rather than stored as an ordinary answer, and a Documents block collects no answer at all. Use earlier qualification answers to show or hide either one. Every visible Schedule appointment question must be booked before submission; a hidden one does not block it. See Cal.com scheduling with logic.
Each action needs a target — the thing it acts on. The target depends on the action type:
Show and Hide reach beyond questions. Target any block on the canvas — a paragraph, heading, image, or layout container — to reveal a note that was hidden by default, or hide content once it is no longer relevant. They can also target individual options inside a choice field, not just the whole question. Hide a block from the block menu first, then write a rule to reveal it.
Every rule is independent, and they all evaluate together. Rules are read top to bottom, across logic blocks, in document order. How several rules on one target combine depends on the action.
So you can point several rules at one block without them fighting. A feedback form has a Radio Buttons question — "What can we help you with?" — with four options, and a "Can we contact you?" email field hidden by default. Four rules each Show that same email field (plus their own follow-up question) for their option. The email field appears no matter which option is picked, and stays hidden only if none is.
> 💡 **Often one rule is enough** >> To reveal a block for several answers, one rule with Any and a condition per answer — or a single{' '} > is not empty condition to cover them all — is easier to read than four rules. Reach for several rules when each option > also needs its own distinct follow-up. >
When two rules disagree on the same target — one Shows a block while another Hides it, or one makes a field required while another makes it optional — and both conditions match at once, the first rule wins. The later, losing rule is flagged in the editor: "This action never applies — an earlier rule already controls its target. Rule order decides: the first rule wins."
One ordering exception: a rule whose condition reads a calculated field runs after the rule that writes it, whatever the document order, so a score is always computed before anything branches on it. Rules that write each other's calculated fields in a loop raise a publish warning that names the chain — break the loop so values resolve predictably.
A question that ends up hidden is never required, whether it was hidden by a rule or hidden from the block menu with no rule to reveal it. The asterisk disappears and submission is not blocked — otherwise a respondent could be locked out of a form by a field they cannot see.
A satisfaction survey asks "How would you rate your experience?" with a 1-5 Star Rating. A logic block below it uses the condition "rating is less than or equal to 3" with the action Show targeting a Text Area field that asks "What could we improve?" Respondents who rate 4 or 5 never see the follow-up.
A signup form has a Radio Buttons question: "Which plan fits you best?" Below it sits a paragraph — "Good choice! Our Pro plan includes priority support." — hidden by default with the block menu's Hide. A logic block reveals it: if plan is{' '} "Pro", Show the paragraph. The encouraging note appears only for Pro pickers, and stays hidden for everyone else.
An event registration form has a Radio Buttons question: "Are you attending in person or remotely?" Two logic blocks follow:
Rules 1 and 2 read the attendance question, so they act when the respondent leaves its page. After that, Next goes on in page order. Rule 3 reads a question on "Venue details", so it acts when the respondent leaves that page. In-person attendees then skip "Streaming setup". Each path collects only relevant information, then both converge on a shared "Confirmation" page.
A lead-qualification form has three Star Rating questions: budget, timeline, and authority. A calculated field named "Lead score" uses a logic block with the Calculate value action to add the value of each rating. A second logic block reads the calculated field: if Lead score is greater than 12, Set next page "Priority follow-up"; otherwise jump to the standard confirmation page.
The URL populates a hidden field named plan (e.g. ?plan=enterprise). A logic block checks: if plan{' '}
is "enterprise", Show the "Dedicated account manager" question and Make required
the "Company size" field. Free-tier respondents never see these questions.
An order form calculates a running total. A logic block uses the condition: if Order total is less than 10, Prevent submit form. The respondent cannot submit until the minimum order threshold is met.
While a prevent rule is active, the button reads as unavailable and the respondent is told why. Type the reason into{' '} Message shown to respondent on the action row — "Your order must total at least 10" — so they know which answer to change. Leave it empty and the form falls back to "This form cannot be submitted with the current answers." (or "You cannot continue to the next page with the current answers." for a navigation block). When several prevent rules fire at once, the first one that carries a message supplies the wording.
> 💡 **Test logic with Preview** >> After setting up your rules, switch to Preview in the top toolbar and fill out the form as a respondent would. Logic > fires in real time in Preview, so you can verify every branch, hidden field, and validation gate before publishing. >