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 and data you can build conditions using static values, or data references docid\ bj9tb3gn vybi1 ehm4rd fields on the same page fields on earlier pages global (non repeating) fields fields within the same repeatable group instance fields from other forms data table values current logged in sparklayer customer data 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 π€ customer dependent forms use currently logged in customer data such as ids, sparklayer group and role, and other data, to conditionally hide or show sections and fields π‘ 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