Skip to main content

​
On Variable Update Node

The On Variable Changed node triggers your workflow when a specific application variable is updated. This enables reactive patterns where one part of your system can signal another to take action.

​
When to Use

  • State-driven workflows - React to status changes in your application
  • Threshold monitoring - Trigger when counters or metrics cross thresholds
  • Data synchronization - Propagate changes across systems
  • Event broadcasting - One workflow updates a variable, others react
  • Decoupled logic - Separate “what happened” from “what to do about it”

​
Example: Order Status Notifications

Notify customers when their order status changes:
1

Set up the variable monitor

Add an On Variable Changed node:
  • Variable name: order_status
  • Change type: any
2

Determine notification content

Use a Switch node on {{variable_changed_1.newValue}}:
  • processing → “Your order is being prepared”
  • shipped → “Your order is on the way”
  • delivered → “Your order has been delivered”
3

Send the notification

Connect to an External API (email or SMS) node to notify the customer.
Workflow structure: 
├── On Variable Changed (order_status)
├── Switch (based on new status)
│   ├── processing → LLM (prepare email) → External API (send email)
│   ├── shipped → LLM (prepare email + tracking) → External API
│   └── delivered → LLM (feedback request) → External API

​
Example: Threshold Alert

Alert when error count exceeds a threshold: Monitor workflow: 
├── On Variable Changed (error_count, increase)
├── Condition (newValue > 10)
│   ├── Met: External API (Slack alert)
│   └── Unmet: (no action)
Configuration:
  • Variable: error_count
  • Change type: increase
Then in your Condition node: 
{{variable_changed_1.newValue}} > 10
AND {{variable_changed_1.previousValue}} <= 10
This ensures you alert only when crossing the threshold, not on every increase.

​
Example: Configuration Propagation

Update multiple systems when a configuration changes: 
Workflow: Config Propagator
├── On Variable Changed (api_rate_limit)
├── Loop (over list of services)
│   └── HTTP Request (update service config)
└── External API (Slack - notify team of change)
This pattern keeps distributed systems in sync when central configuration changes.

​
Use Patterns

​
Event Broadcasting

One workflow sets a variable, multiple workflows react: 
Workflow A (main process):
└── Set Variable (status = "complete")

Workflow B (notifications):
├── On Variable Changed (status, specific: "complete")
└── External API (send notifications)

Workflow C (cleanup):
├── On Variable Changed (status, specific: "complete")
└── Execute Code (archive data)

​
State Machine

Build state machines where transitions trigger actions: 
Variable: application_state
Values: draft → review → approved → published

Workflow: State Transition Handler
├── On Variable Changed (application_state)
├── Switch
│   ├── review → External API (notify reviewers)
│   ├── approved → External API (notify author)
│   └── published → Execute Code (update search index)

​
Counter-Based Triggers

Trigger actions based on accumulated counts: 
# When signup count reaches milestones
├── On Variable Changed (signup_count, increase)
├── Condition (newValue % 100 == 0)
│   └── Met: External API (celebrate milestone in Slack)

​
Tips

Use specific value triggers when you care about a particular state, and any triggers when you need to react to all changes.
Access both previousValue and newValue to implement transition logic - different actions for different state changes.
Avoid circular dependencies where a variable change triggers a workflow that changes the same variable. This can create infinite loops.
Variable changes from Set Variable nodes within the same workflow don’t trigger On Variable Changed events in that same workflow run. This prevents self-triggering.

​
Settings

​
name
string
default:"On Variable Changed"
Display name shown on the canvas.
​
key
string
default:"variable_changed_1"
Unique identifier for referencing outputs.
​
variableName
string
required
The name of the application variable to monitor.
​
changeType
string
default:"any"
What type of change to trigger on:
  • any - Any change to the variable
  • specific - Only when changed to a specific value
  • increase - When numeric value increases
  • decrease - When numeric value decreases
​
targetValue
any
For specific change type: the value that triggers the event.

​
Outputs

​
variableName
string
Name of the variable that changed.
​
previousValue
any
The value before the change.
​
newValue
any
The current value after the change.
​
changedAt
string
ISO timestamp of when the change occurred.
​
changedBy
string
Identifier of what triggered the change (workflow ID, node key, or “manual”).

Update Variable

Update variables that trigger this event.

Condition

Add logic based on the changed value.