Dylan's Salesforce Docs | Agent Script | Understanding Variables

Variables let agents deterministically remember information across conversation turns, track progress, and maintain context throughout the session

Variables

Variables let agents deterministically remember information across conversation turns, track progress, and maintain context throughout the session. All variables are defined in the variables block and are accessible to all subagents.

Variables hero

Variable Types

There are two types of variables:

Type	Description	Default Value	Agent Can Modify
Regular	Standard variables with optional default values	✅ Yes	✅ If `mutable`
Linked	Value tied to a source (e.g., action output)	❌ No	❌ No

Regular Variables

Supported Types

Type	Notes	Example
`string`	Alphanumeric text	`name: mutable string = "John Doe"`
`number`	Integers and decimals (IEEE 754 double)	`age: mutable number = 25`
`boolean`	`True` or `False` (case-sensitive)	`is_active: mutable boolean = True`
`object`	Complex JSON objects	`order: mutable object = {"SKU": "abc123"}`
`date`	Any valid date format	`start_date: mutable date = 2025-01-15`
`id`	Salesforce record ID	`record_id: mutable id = "0015000000XyZ12"`
`list[type]`	List of values of specified type	`scores: list[number] = [95, 87.5, 92]`

Examples

variables:
  # String variable with default
  customer_name: mutable string = ""
  
  # Number variable
  retry_count: mutable number = 0
  
  # Boolean flag
  is_verified: mutable boolean = False
  
  # Object for complex data
  customer_info: mutable object = {}
  
  # List of strings
  selected_options: mutable list[string] = []
  
  # Immutable variable (cannot be changed)
  max_retries: number = 3

Mutable vs Immutable

Use mutable to allow the agent to change the variable's value
Omit mutable to ensure the value is never changed

Linked Variables

Linked variables have their value tied to a source, such as an action's output. They cannot have default values and cannot be set directly by the agent.

variables:
  # Linked to action output
  order_status: string linked to @actions.get_order.outputs.status
  
  # Linked to another source
  weather_temp: number linked to @actions.get_weather.outputs.temperature

Supported Types for Linked Variables

string
number
boolean
date
id

Referencing Variables

Context	Syntax	Example
Script logic	`@variables.name`	`if @variables.is_verified:`
Prompt instructions	`{!@variables.name}`	`The customer name is {!@variables.customer_name}`

In Logic

if @variables.retry_count >= @variables.max_retries:
  -> transition to @subagent.escalation

In Prompts

reasoning:
  instructions: |
    The customer's name is {!@variables.customer_name}.
    Their order ID is {!@variables.order_id}.
    Help them with their request.

Setting Variables

Directly in Logic

-> set @variables.retry_count = @variables.retry_count + 1
-> set @variables.is_verified = True

From Action Outputs

-> run @actions.get_customer_info
-> set @variables.customer_name = @actions.get_customer_info.outputs.name

Let the LLM Set Variables (Slot Filling)

Use ... to instruct the LLM to set a variable's value based on user input. This is called slot filling.

variables:
  first_name: mutable string
    description: "The customer's first name"
  last_name: mutable string
    description: "The customer's last name"

reasoning:
  actions:
    - capture_user_info:
        description: "Capture the customer's name from conversation"
        @utils.set @variables.first_name = ...
        @utils.set @variables.last_name = ...

Slot Filling Tip

Include a description on variables you want the LLM to set. The description helps the LLM understand what information to extract from the conversation.

Common Use Cases

variables:
  current_temperature: mutable number = 0

subagent weather_check:
  actions:
    get_weather:
      target: flow://Get_Current_Weather_Data
      outputs:
        temperature:
          type: number
  reasoning:
    instructions:
      -> run @actions.get_weather
      -> set @variables.current_temperature = @actions.get_weather.outputs.temperature

Now any subagent can access @variables.current_temperature.

Tracking Conversation Progress

variables:
  verification_step: mutable string = "not_started"
  attempts: mutable number = 0

subagent verification:
  reasoning:
    instructions:
      if @variables.verification_step == "not_started":
        -> set @variables.verification_step = "email_sent"
        -> run @actions.send_verification_code
      if @variables.verification_step == "email_sent":
        | Ask the customer to enter the verification code they received.

A fuller variables-heavy example

This is the kind of example that makes variables click: one subagent writes state, another reads it later, and the conversation stays coherent.

variables:
  current_temperature: mutable number = 0
  appointment_confirmed: mutable boolean = False
  selected_day: mutable string = ""
  retry_count: mutable number = 0
  latest_visit_id: id linked to @actions.create_service_visit.outputs.visit_id

subagent weather_check:
  actions:
    get_weather:
      target: flow://Get_Current_Weather_Data
      inputs:
        city:
          type: string
          required: True
      outputs:
        temperature:
          type: number
        weather_summary:
          type: string
  reasoning:
    instructions:
      -> run @actions.get_weather
      -> set @variables.current_temperature = @actions.get_weather.outputs.temperature
      |
      Explain the weather conditions clearly before the scheduling flow continues.

subagent schedule_visit:
  actions:
    create_service_visit:
      target: flow://Create_Service_Visit
      inputs:
        service_day:
          type: string
          required: True
      outputs:
        visit_id:
          type: id
  reasoning:
    instructions:
      if @variables.current_temperature < 35:
        | Let the customer know freezing temperatures may affect the visit.
      if @variables.selected_day != "":
        -> run @actions.create_service_visit
        -> set @variables.appointment_confirmed = True
      |
      Use the stored day, weather, and retry count to guide the rest of the conversation.

Naming Rules

Variable Naming Standards

Variable names must follow Salesforce developer name standards:

Begin with a letter (not underscore)
Alphanumeric characters and underscores only
Cannot end with underscore
No consecutive underscores (__)
Maximum 80 characters
Recommended: Use camelCase for variable names

Understanding Variables

On this page