Template Evaluation in Data
Workflows evaluate template placeholders such as {{ step_1.body.name }}, {{ ds.customer_name }} and {{ vault.API_KEY }} in the settings you write for each step. Data that arrives from outside the workflow can contain the same syntax: a support ticket that quotes {{ broker.state }}, an email that includes a template, or a value an agent passes in. These settings decide whether such placeholders are evaluated or kept as literal text.
When placeholders inside incoming data are evaluated, anyone who can send data to the workflow (for example, the caller of a public webhook) can make a run fail by referencing a name that does not exist, or pull datastore values and vault secrets into later steps. Set both workflow settings to Treat as literal text unless the workflow relies on that behavior.
Placeholders you write in step settings are always evaluated, whatever these settings say.
Workflow settings
Open the workflow, select Settings, and find Template Evaluation in Data. Each setting saves immediately.
| Setting | Applies to |
|---|---|
| Incoming data | Runtime input values: the webhook body, headers and query, emails, form and sheet rows, uploaded file contents, and inputs passed by agents, the Run Flow API or a Call Flow step. A value equal to the default you configured for that input counts as your own text and is always evaluated. |
| Inserted values | Text inserted into a step's settings for a placeholder (from the trigger, a previous step, an input or the datastore), and any later step that would otherwise evaluate that text again (API requests, datastore values, loop conditions, Final Output mappings, Python arguments, Call Flow inputs). |
Each setting has three modes:
| Mode | Behavior |
|---|---|
| Treat as literal text | Placeholders inside the data are never evaluated and never cause errors. |
| Evaluate, but never resolve vault secrets | Step and datastore placeholders inside the data are evaluated; {{ vault.* }} stays literal. |
| Evaluate templates (legacy) | Placeholders inside the data are evaluated like your own settings. |
Data is only fully treated as literal text when both settings are set to Treat as literal text. With only Incoming data set to literal, a webhook payload no longer fails the trigger step, but its text is still evaluated when a later step inserts it.
New workflows are created with both settings set to Treat as literal text. Workflows created earlier, and imported or cloned workflows whose source has no setting, keep the legacy behavior until you change it. The settings are stored with the workflow, so publish it to apply a change to the Live version.
The same settings are available through the API as incoming_data_templates and inserted_value_templates on POST /tools/custom and PUT /tools/custom/{tool_id}, with the values literal, evaluate_no_secrets and evaluate.
Loop expressions
Loop expression conditions are evaluated with a restricted evaluator that accepts comparisons, and/or/not and basic arithmetic. When Inserted values is not set to legacy, each placeholder in the expression is used as a value, never as part of the expression itself.
Webhook responses
When a webhook uses Wait for Workflow to Complete and the run fails, the caller receives a generic error with the execution_id. The failure details are in the workflow's execution history.
If the workflow has no Final Output or Return Response step, the webhook returns every step's output by default. Clear Return every step's output in the webhook trigger to return only the last step's output.
API tools
API tools used by agents have a matching setting, Templates in agent-supplied values, in the tool's Settings card (argument_value_templates in the tool config). It controls whether placeholders inside the argument values an agent sends are evaluated. Placeholders you write in the URL, headers and parameter defaults are always evaluated. New API tools use Treat as literal text; existing tools keep the legacy behavior until you change it.