Flow variables and templates

Template variables let you pass data between steps and reference flow inputs using {{variable}} syntax.

Basic syntax

Reference variables with double curly braces:

{{variableName}}

This works in any text field: prompts, URLs, request bodies, conditions, etc.

Flow input

When you trigger a Flow through the API, pass values in the inputs field. Access them directly by key name:

Name: {{customerName}}
Email: {{email}}
Order ID: {{orderId}}

For record-based executions, access record metadata with the _record prefix:

Customer: {{_record.metadata.customer_name}}
Status: {{_record.metadata.status}}

Step outputs

Reference the output of earlier steps by their outputVariable name:

{{summary_result}}

If the output is a JSON object, access nested fields with dot notation:

Summary: {{generate_summary}}
Sentiment: {{analyze_sentiment.label}}
Confidence: {{analyze_sentiment.score}}

Nested properties

Use dot notation to access nested data:

{{customer_data.metadata.tier}}
{{api_response.data[0].name}}
{{_record.metadata.address.city}}

Array access

Reference array items by index:

{{search_results[0].metadata.title}}
{{search_results[1].metadata.content}}

System variables

Runtype provides system variables prefixed with _:

The _schedule variable is available only in schedule-fired executions and includes .id, .name, .cron, .timezone, .lastRunAt, and .nextRunAt.

The _endUser variables are populated only when the caller includes an endUser: { id, email?, ... } object on the dispatch request or the agents/:id/execute call. They identify your customer’s individual end-user, who is distinct from _user (the Runtype account holder). Use them in agent memory profileTemplate values like {{_endUser.id}} to keep long-term memory separate per end-user in multi-tenant SaaS products. If _endUser is absent and a template references it, the reference resolves to an empty string.

The _tenant variables are populated when the caller includes a tenant: { id, ... } object on the same calls. The Product Tenant is the builder’s customer or workspace inside your Product — the scope shared by all of a tenant’s end-users — nested under the Builder Org (_user) and above the individual end-user (_endUser). Use {{_tenant.id}} to address account-level shared state and {{_endUser.id}} to address per-user state. Like _endUser, _tenant is caller-asserted and resolves to an empty string when absent.

Default values

Provide fallbacks when variables might be undefined:

{{customerId || "unknown"}}
{{customerData.tier || "standard"}}

The || operator uses truthy fallback. Use ?? for nullish fallback (only triggers on null/undefined, not empty string or 0).

String concatenation

Combine strings and variables:

Customer {{customerName}} placed order #{{orderId}} on {{_now.date}}

Calculations and conditional logic

For calculations, ternary expressions, and complex logic, use a transform-data step. The {{variable}} template syntax supports variable references and fallback chains, but not arithmetic or comparison operators.

Using variables in JSON

When building JSON request bodies or metadata:

1
{
2
  "customer": "{{customerId}}",
3
  "summary": "{{generate_summary}}",
4
  "amount": {{calculate_total}},
5
  "timestamp": "{{_now.iso}}"
6
}

Note: Numbers and booleans don’t need quotes. Strings do.

Variables are evaluated at runtime. If a referenced step has not executed yet, the variable will be undefined.

Debugging variables

Use a transform-data step to inspect variable values. Flow variables are available directly by their outputVariable name:

1
return {
2
  debug: true,
3
  customer_data_value: customer_data,
4
  analysis_value: analysis
5
};

Check the step output in the execution results to see the returned values.

Variable scope

Variables are scoped to the Flow execution:

• Can reference any earlier step’s outputVariable in the same Flow
• Cannot reference variables from other Flows
• Variables set inside conditional branches are accessible after the conditional completes

Best practices

• Use descriptive step names: Makes variable references clearer
• Check for null: Use defaults or conditionals when data might be missing
• Keep nesting shallow: Deep property chains are error-prone
• Test with real data: Ensure variables resolve correctly in all scenarios

Next steps

• Using prompt steps for AI generation with variables
• Using transform-data steps for complex variable manipulation
• Using conditional steps for variable-based branching
• Debugging flows to trace variable values