Skip to main content

​
Triggers

Triggers control when nodes execute in your graph. By default, nodes run whenever data arrives on any input, but you can configure specific inputs as triggers to have more control over execution timing. Understanding triggers is key to building efficient, predictable data pipelines.

​
What is a Trigger?

A trigger is an input port that causes a node to execute when data arrives on it. When data arrives on a trigger input:
  1. Node wakes up - The node’s execution function is called
  2. Data is received - Data is read from all input ports (not just triggers)
  3. Code runs - Your node’s code executes with the received data
  4. Output is sent - Results are sent through output ports
Think of triggers as doorbells. When someone rings the doorbell (data arrives on trigger), you wake up (node executes), check what’s at the door (read inputs), and respond (send outputs).
Triggers enable event-driven execution. Nodes don’t run continuously—they wait for data and execute only when triggered.

​
Why Use Triggers?

Control Execution

Control exactly when nodes run. Configure which inputs trigger execution for precise timing.

Efficient Processing

Nodes only run when needed. No polling or busy-waiting—just event-driven execution.

Synchronization

Synchronize multiple inputs. Wait for data on specific inputs before processing.

Performance

Avoid unnecessary executions. Only process when relevant data arrives.

​
Default Behavior

By default, all inputs are triggers. This means:
  • When data arrives on any input, the node executes
  • The node reads data from all inputs (not just the one that triggered)
  • This is the simplest model and works for most cases
You don’t need to configure triggers for simple cases. The default behavior (all inputs trigger) works well for most pipelines.

​
Explicit Triggers

You can configure specific inputs as triggers for more control:

​
Setting Triggers

To set an input as a trigger:
  1. Select the node
  2. Open the properties panel
  3. Find the input port you want to configure
  4. Check the “Trigger” checkbox
The input port should turn red and show a ★ star marker, indicating it’s a trigger.

​
Visual Indicators

Trigger inputs are visually distinct:
  • Red port circle - Instead of the normal blue
  • ★ star marker - Next to the input name
  • Properties panel - Shows “Trigger: Yes”
Visual Note: A screenshot showing a normal blue input vs a trigger input (red + star) would be helpful here.

​
Trigger Patterns

​
All Inputs Trigger (Default)

All inputs trigger execution: 
Input 1 (trigger) → Node executes when data arrives on any input
Input 2 (trigger)
Input 3 (trigger)
Use when: You want the node to run whenever any data arrives.

​
Single Input Triggers

Only one input triggers execution: 
Input 1 (trigger) → Node executes only when data arrives on Input 1
Input 2 (not trigger)
Input 3 (not trigger)
Use when: You want to control execution based on a specific input (e.g., a clock signal).

​
Multiple Specific Triggers

Some inputs trigger, others don’t: 
Input 1 (trigger) → Node executes when data arrives on Input 1 or Input 2
Input 2 (trigger)
Input 3 (not trigger) → Input 3 is read but doesn't trigger
Use when: You want to synchronize on specific inputs while still reading others.

​
Trigger Use Cases

​
Clock-Driven Processing

Use a clock input as the only trigger: 
Clock (trigger) → Processor → Output
Data (not trigger)
The processor runs on each clock tick, reading the latest data value.

​
Synchronized Processing

Wait for data on multiple inputs before processing: 
Input A (trigger) → Processor → Output
Input B (trigger)
The processor only runs when data arrives on both Input A and Input B.

​
Event-Driven Actions

Trigger on events, read configuration from non-trigger inputs: 
Event (trigger) → Action Node → Output
Config (not trigger)
The action node runs on events but always has access to the latest configuration.

​
Trigger Behavior Details

​
Data Reading

When a node is triggered:
  1. Trigger input - Data that arrived (causes execution)
  2. Other inputs - Latest available data is read
  3. All inputs - Available to your code
Even if an input isn’t a trigger, your code can still read from it. The node just won’t execute when data arrives on non-trigger inputs alone.

​
Execution Order

When multiple triggers fire simultaneously:
  • One execution - The node executes once
  • All data read - Data from all trigger inputs is available
  • Deterministic - Execution order is consistent

​
Missing Data

If a trigger fires but other inputs have no data:
  • Node still executes - Trigger causes execution
  • Missing data - Non-trigger inputs may be empty/null
  • Your code handles it - Check for data availability in your code
Always check if data is available before using it. Non-trigger inputs may not have data when a trigger fires.

​
Best Practices

Default is Usually Fine

Most nodes work fine with all inputs as triggers. Only configure explicit triggers when needed.

Clear Intent

Use triggers to make execution intent clear. If a node should run on clock ticks, make clock the only trigger.

Handle Missing Data

Always check for data availability. Non-trigger inputs may not have data when triggers fire.

Document Triggers

Document why specific inputs are triggers. Future you will appreciate the explanation.

​
Common Patterns

​
Publisher Pattern

Publisher nodes typically have no inputs (or only configuration inputs): 
Publisher Node (no inputs) → Output
Runs continuously or on a timer (not data-driven).

​
Processor Pattern

Processor nodes typically have all inputs as triggers: 
Input (trigger) → Processor → Output
Runs whenever new data arrives.

​
Subscriber Pattern

Subscriber nodes typically have all inputs as triggers: 
Input (trigger) → Subscriber (logs/displays)
Runs whenever new data arrives.

​
Clock-Driven Pattern

Nodes that run on a clock signal: 
Clock (trigger) → Processor → Output
Data (not trigger)
Runs on clock ticks, reads latest data.

​
Troubleshooting Triggers

Problem: Node doesn’t run even when data arrives.Solutions:
  • Check that at least one input is configured as a trigger
  • Verify data is actually arriving (check topic/subscriber)
  • Look for errors in node code that might prevent execution
  • Check that the graph is running (not just generated)
Problem: Node runs more frequently than expected.Solutions:
  • Check if multiple inputs are triggers (each can cause execution)
  • Verify data arrival rate matches expectations
  • Consider using a single trigger input if synchronization isn’t needed
  • Check for feedback loops that might cause rapid execution
Problem: Non-trigger inputs don’t have data when node executes.Solutions:
  • This is expected behavior—non-trigger inputs don’t cause execution
  • Check data availability in your code before using it
  • Consider making the input a trigger if you need it to cause execution
  • Use default values or handle missing data gracefully

​
Next Steps

Now that you understand triggers, learn more:

Nodes

Learn how nodes use triggers to control execution.

Ports and Links

Understand how input ports can be configured as triggers.

How-to Guides

Learn how to add and configure ports, including triggers.

Examples

See trigger patterns in action with real examples.