Jetstack uses expressions to make configuration fields dynamic. Expressions are evaluated through the active-resource expression pipeline, not by simple text substitution. That pipeline can resolve variables, run code processor functions, translate table-column references, and use utility helpers.
Expressions are one of the most important cross-cutting mechanisms in the platform. They appear in:
Because expressions appear in so many places, inconsistent expression design leads directly to confusing implementations.
Jetstack registers these dynamic expression syntaxes:
| Syntax | Meaning | Typical use |
|---|---|---|
{$...} |
variable or property resolution | object values, nested relations, current context fields |
{{ ... }} |
alternate variable syntax | template-safe or visually clearer variable resolution |
{=...} |
code processor or math expression | comparisons, boolean logic, function calls, calculations |
{%...%} |
table-column resolution | query and SQL-aware dynamic configuration |
{?...} |
utility helper resolution | helper-level expression handling |
These formats can appear in one field or be combined, depending on the target configuration surface.
Jetstack evaluates expressions by repeatedly resolving the smallest supported dynamic segments until no dynamic segments remain.
This matters because a field can resolve in several stages:
That is exactly how many property condition fields behave.
Expressions are evaluated against context. The caller can evaluate an expression:
Depending on where an expression runs, the context may include:
This is why the same expression string can behave differently in different platform areas.
show_conditionsadd_conditionsedit_conditionsThese fields usually resolve to booleans after variable expansion and code evaluation. They decide whether a property is visible, addable, or editable in the current form context.
default_valueform_initial_valuecalculationmaskvalue_switchThese fields can alter form behavior, display behavior, or resulting values.
These often evaluate before a query is run and may need strict resolution.
showConditionCanvas items often accept expression-based values, but the meaning depends on canvas scope. A field may expect:
Automation actions can use trigger values, previous endpoint parameters, local variables, app parameters, query helpers, and secrets through expressions.
Bad expression design usually looks like one of these:
Good expression design usually looks like:
{$...} or {{ ... }} for reading values from context{=...} for logic, comparison, or function-based transformation{%...%} only when a feature explicitly needs table-column semanticsSome callers expect:
That is why an expression that works in one place may need adjustment in another.
{=toBool({$this.is_active.raw()}) && {$this.customer_type} == "enterprise"}
Use this when a field should appear only for active enterprise customers.
{$this.owner.full_name}
Use this when the form should begin with a value derived from related context.
{=date_format(date_add(date_now(), "P14D"), "Y-m-d")}
Use this when the default should be two weeks from now.
show_conditions, add_conditions, and edit_conditions close to the property they control.