Skip to main content
Conditional Visibility decides whether a single section on a Page renders at all. You write one CEL expression on the section; it is evaluated at scan time against that Item, that visitor’s device, and the current time. True renders the section, false leaves it out entirely. This is a show/hide decision about one thing on a Page. It is not how you choose between two URLs — that is a different mechanism — the Destination’s own conditional routing rules — and it works even when there is no Page at all.

​
Where the condition lives

In the Page Editor, select a section, then open the Visibility group in the Properties panel on the right. The field is labeled Show When (CEL Expression). Any section type can carry a condition — not just Destination buttons. A Text block, a Banner, a whole Container (which hides its children with it), an ImageSection: all of them accept one. Leaving the field empty means the section is always visible. As you type, a Preview badge next to the field reads Visible or Hidden, evaluated against whichever Item you have selected in the editor. Switch the previewed Item to check the condition against real data instead of your base template.

​
What a condition can look at

Everything the Page itself can bind to is available in a condition:

​
Working examples

Show a section only for one equipment type:
Show a section only for Items carrying a tag:
Show a warning banner only when a status field says so:
Combine conditions with &&, ||, and !, and group with parentheses:
Restrict a section to one Collection when the Page template is shared:

​
A wrong condition and an unmet condition look identical

If a condition references something that does not exist, the whole expression evaluates to false — silently. The visitor sees no error; the section simply is not there. Even in the editor, the Preview badge reads Hidden rather than Error, because a failed lookup is treated as a false result rather than as a failure. That makes these three situations indistinguishable at a glance:
  • A genuine miss — this Item really is not a forklift.
  • A typo — item.tpye == "forklift", or a field name whose capitalization does not match (field names are case-sensitive).
  • An invented value — today > item.dueDate. There is no today. time exposes only the parts listed above — no absolute date and no date arithmetic, so “show this when the inspection is overdue” cannot be expressed. Use a status field you maintain (item.testStatus == "expired") instead of comparing dates.
The practical defense is to build conditions by picking fields from the editor’s suggestions rather than typing them, and to verify against a real Item that you know should match before deploying.

​
Expression limits

Every condition is validated before it is evaluated, and a condition that breaks a limit is rejected in the editor rather than silently ignored:
  • Maximum 500 characters
  • Maximum nesting depth of 10 for brackets and parentheses
  • Maximum 20 operators
  • Parentheses and brackets must balance
If you are anywhere near these ceilings, the logic almost certainly belongs in a field on the Item rather than in an expression on the Page.

​
Before you add a condition

Ask whether showing everything is simpler. A Page with four buttons where people tap the one they need is easier to build, easier to debug, and easier for a contractor to understand than four conditions. Conditional Visibility earns its place when the wrong button is actively harmful — a crane inspection form on a forklift, for example. Also note that an ActionLink already hides itself when its own URL binding cannot resolve, with no condition needed — see ActionLink: The Destination Button. You do not need a condition to suppress a button that has nowhere to go.