Scope resolvers define what values can be discovered, selected, and resolved in builder-assisted dynamic configuration. In Jetstack, the two most important resolver families are:
- automation scope
- canvas scope
They sit on top of a default traversal mechanism that can walk available fields, object properties, methods, and helper filters.
Scope resolution explains:
- why a builder can suggest certain top-level keywords
- why some chains are valid in an automation but not in a canvas
- why some nodes expose parameters
- why a resolved value may be an object in one place and a scalar in another
Without scope resolution, builder-assisted configuration would be guesswork.
Each resolver defines four important behaviors:
getKeywords
returns the top-level roots a builder may exposegetAvailableFields
returns what can be accessed next from a current selectiongetFieldParameters
returns callable parameters for method-like nodesresolveValue
resolves the final selected chain into a runtime value
The default resolver then interprets each step by walking objects, array-like structures, methods, and globally available filters.
Automation scope is designed around execution context. Depending on the running automation and action, it can expose:
- trigger parameters
- previous endpoint parameters
- local automation variables
- global variables
- app parameters
- current data query
- secrets access through the code processor
This makes automation expressions ideal for branching, routing, notifications, integration payloads, and task scheduling.
Canvas scope is designed around interactive UI context. Depending on the current item and runtime situation, it can expose:
- current canvas
- current object or wrapper object
- parent object
- iterator context
- target item values
- item-specific builder options
This makes canvas expressions ideal for context-aware rendering and composition.
When you use a builder that offers scope-driven value selection, the process is usually:
- choose a top-level keyword
- choose a field or callable segment
- provide parameters if the segment is callable
- continue deeper if the result is traversable
- resolve the final value at runtime
This is more reliable than hand-writing deep chains because the builder constrains the available path to what the scope actually exposes.
A common canvas design question is whether a parameter should receive:
- a fixed string
- a parent object chain
- another top-level scope value
- a computed expression
Use these rules:
- choose a fixed string when the value is purely presentational and static
- choose a parent or wrapper object chain when the value should follow the current object context
- choose another top-level scope when the value belongs to iterator, action target, or a specialized canvas runtime
- choose a full expression when a value must combine several sources or run logic
Common scope problems include:
- selecting a field that is not valid from the chosen root
- assuming a method parameter shape without checking builder-provided parameters
- reusing an automation expression inside a canvas without adapting the root scope
- expecting a scalar where the path resolves to an object or array
- Keep chains short enough that another implementer can still explain them.
- Prefer stable roots such as current object, trigger, or known parent context.
- Use builder-assisted parameter selection for callable fields.
- When a chain becomes too complex, consider introducing an automation variable or a simpler model-level field.