Conditional Logic

introduction conditional logic lets your forms adapt based on customer input you can show or hide fields, sections, or pages dynamically — helping keep forms shorter, clearer, and more relevant for b2b customers instead of showing every possible field upfront, you can guide users through a progressive experience based on their answers 🧠 how conditional logic works each field can include rules that control when it appears when a customer changes a value sparklayer checks your conditions visibility updates instantly the form adapts in real time ⚙️ adding conditional logic to apply logic to a field select a field in the form builder open the display logic tab click add condition choose the field, operator, and value save your changes each condition follows a simple structure part description field the field you want to reference operator how the value is compared value the condition that must be met example show "state" when country equals "us" 👁 visibility actions when creating logic, you decide how the field behaves show when the field only appears if the condition is met best used for region specific address fields optional business details advanced settings hide when the field disappears if the condition is met best used for skipping irrelevant questions simplifying long forms removing unnecessary options both approaches help reduce form friction and improve completion rates 🧩 building conditions simple conditions use a single rule to control visibility show phone when contact preference equals "call" multiple conditions combine rules using and or or logic show shipping address when delivery method = ship and country = united kingdom condition groups (advanced) group multiple rules acknowledges more complex workflows show discount field when (customer type = premium or order total > 1000) and promotions enabled = true condition groups allow more precise control without duplicating fields 🔎 supported condition types sparklayer supports a range of comparisons so you can build flexible logic comparison rules use case example equals / not equals customer type = trade greater or less than order value > 500 numeric thresholds quantity ≥ 10 text based rules use case example contains email contains “@company” starts with phone starts with +44 ends with email ends with edu value checks use case example has value email is not empty boolean checks approved is true length checks useful for validating structured inputs postcode length reference codes order numbers these operator types allow forms to respond intelligently to different input patterns 🔗 referencing other fields you can build conditions using fields on the same page fields on earlier pages global (non repeating) fields fields within the same repeatable group instance inside repeatable groups, logic can applies to the current item — helping keep behaviour predictable when customers add multiple entries 🙈 hidden field behaviour when a field becomes hidden it is removed from the ui validation rules no longer apply required settings are ignored the value is preserved unless configured otherwise 🧾 common sparklayer use cases 🌍 region based forms show different fields depending on country selection ⚙️ advanced settings hide complex configuration options until a toggle is enabled 📦 progressive disclosure gradually reveal extra options instead of overwhelming customers with long forms 💡 best practices keep logic simple avoid deeply nested conditions use clear field labels document complex rules for your team utilise the group field to apply display logic once to a list of sub fields to reduce duplicated logic test thoroughly try every condition path test with empty fields think about ux don’t hide too much at the start give context when new fields appear group related logic together consider performance very complex logic can slow large forms if your form grows significantly break into multiple pages simplify nested conditions reduce unnecessary dependencies between field