Conditional logic

Five properties in the Logic category control element state. Each takes a true/false expression and re-evaluates automatically when referenced fields change.

Property	While the expression is true…
Visible if	the element is shown (hidden otherwise)
Disable if	the element is visible but inactive
Require if	the element is required
Read only if	the value is visible but locked
Reset if	the moment it becomes true, the value is cleared/reset to default

Lesson 9Conditional logicWatch on YouTube

Chapters (7)

Building a rule without writing it

Every logic editor has two tabs: Code and Visual builder. The visual builder lets you put a rule together from dropdowns, so you do not need to know the expression syntax at all.

Each row is one condition: pick a field, pick what should be true about it, and give a value. The rule list follows the field's type, in plain words: a text field offers is equal to, contains, starts with, is empty and so on; a number adds is greater than and friends; a date says is after and is before; a checkbox is simply is Yes or is No. The value box follows the field too: a dropdown or radio field offers its own options, a number field takes a number, a date field opens a date picker. Compare with another field swaps the value for a second field.

With more than one row, Match all conditions or Match any condition decides how they combine.

The line on top reads the rule back as a sentence, for example When Team is equal to "Sales" and Age is greater than 18, and the expression that will be saved is shown underneath, so you can check it and pick up the syntax as you go. A row that is not filled in yet is marked and left out until it is complete.

When you open an existing rule, the builder reads it back into rows. If it uses something the rows cannot show (mixed and and or, brackets, other functions), the builder says so and leaves it alone: edit it on the Code tab, or choose Start over in the builder to replace it. Editors open on the visual builder whenever it can show the rule.

Visible if

{clientType} == "company"            show for companies only
!isEmpty({email})                    show once email is entered
contains({services}, "delivery")     show when "delivery" was picked

Put visibleIf on a panel to toggle a whole section at once. A hidden element keeps its configuration but is skipped in validation by default.

Disable if

{approvalStatus} == "approved"       lock after approval
{age} < 18                           inactive for minors
!containsAny({roles}, ["admin", "editor"])

Use disable when the user should see that the option exists; use visible when it's irrelevant.

Require if

{personType} == "company"            company code required for companies
{amount} > 10000                     justification required for large sums
{country} != "LT"                    tax ID required for foreign clients

Read only if

{status} == "submitted"              freeze after submission
notEmpty({externalReference})        imported values can't be edited
{__variables.mode} == "view"         whole form in view mode

Reset if

Clears stale answers when their premise disappears:

{personType} != "company"            clear companyCode when switching to person
!contains({supportTypes}, "training")   clear trainingDate if training unselected

Without a reset rule, a hidden field keeps its old value, and that value is still submitted.

Logic inside repeaters

Inside a Dynamic panel or a Dynamic table, the same five properties are evaluated once per row, against that row's own values. Write the condition with the row context rather than a field name:

panel.dpDriver > 10        dynamic panel: this entry's field
row.quantity > 0           dynamic table: this row's cell

Each row then decides for itself. In a panel of order lines, visibleIf: panel.quantity > 0 hides the discount field only in the lines that have no quantity, and leaves the other lines untouched. The same goes for Require if, so a row can be mandatory while its neighbours are not.

Referring to a plain field name inside a repeater still points at the form-level field of that name, which is what you want for conditions like visibleIf: {orderType} == "wholesale" applied to every row at once.

When the rule re-runs

A rule is re-evaluated according to the element's Logic execution mode, in the Behavior category. Left alone it is On blur, so the rule waits until the field loses focus. That suits a heavy expression on a long text field and almost nothing else: someone typing an amount watches the dependent field sit still and concludes the logic is broken.

Set it to On change on any element whose rule should follow the typing. Validation has its own Validation execution mode with the same default, so set that one as well when an error should appear while the user types rather than after they leave the field.

Several logic properties on one element

They are independent and all apply. An element can be visible, required, and read only at the same time, and the combination is resolved in one pass, so the field is correct on the first change rather than after a second edit.

Visible if    {n1} > 10
Require if    {n1} > 10
Read only if  {approved} == true

Complete example

Order form: "Deliver to a different address?" (single checkbox otherAddress) with a delivery panel:

Element	Property	Expression
Panel deliveryPanel	Visible if	{otherAddress} == true
Text deliveryStreet	Require if	{otherAddress} == true
Text deliveryStreet	Reset if	{otherAddress} != true

Result: the section appears only when needed, is mandatory when shown, and cleans up after itself when hidden.