Visibility & Conditional Disable

A loan form shouldn't ask everyone for a "co-signer's income," and a promo-code field shouldn't stay editable forever after it's been used. Building that kind of behavior used to mean asking engineering for custom logic on a specific field. Now it's something any form author can set up directly, using the same formula engine that already powers default values and calculated totals.

1. One formula engine, everywhere

Pre-filled values, computed totals, and conditional field behavior all evaluate through the same shared formula engine. Write a formula once — referencing other fields on the form by name — and it behaves identically no matter which surface it's used on. There's no separate "visibility syntax" to learn on top of what you already use for default values.

2. Show or hide a field based on other answers

Open a field's Visibility settings and write a formula referencing other fields on the form — for example, only showing a "Co-signer income" field when a "Do you have a co-signer?" field is answered Yes. The field re-evaluates live as the respondent fills out the form, so it appears or disappears the moment the relevant answer changes — no page reload, no separate "next" step required.

A hidden field is never required for submission, even if it was originally marked required — so a respondent is never blocked by a field they can't see.

3. Lock a field once it shouldn't be edited anymore

Open a field's Conditional Disable settings and write a formula the same way. For example, disable a "Discount code" field once a valid code has already been applied, or lock a "Shipping address" field once an order has moved to "Processing." The field becomes read-only automatically, in real time, without a separate save step or a workflow node to police it.

4. Formulas stay live as the form is filled out

Both Visibility and Conditional Disable re-check their formulas continuously against the respondent's current answers — not just once when the form loads. If someone changes an earlier answer, dependent fields immediately reflect that: a field that was hidden can reappear, and one that was locked can unlock, the moment the underlying condition is no longer true.

Best practices

• Reference the field, not a description of it — formulas evaluate against actual field values, so make sure the field you're referencing holds the value you expect (e.g. an option's stored value, not its display label).
• Use Visibility to reduce clutter, Conditional Disable to protect state — hide fields that are simply irrelevant to the respondent's path; disable fields that were relevant but shouldn't change anymore.
• Don't rely on a hidden field to enforce validation — hidden fields are automatically excluded from required-field checks, so any validation you need should live on a field the respondent can actually see.
• Test with real answer combinations — since logic re-evaluates live, walk through the form yourself changing earlier answers to confirm dependent fields show/hide and lock/unlock the way you expect.