List Change Trigger — Reactive Workflows That Fire When Your Data Changes

Need a workflow that runs the moment someone adds a row to your trading journal, updates a watchlist price, or deletes an expired entry? The new List Change Trigger does exactly that — it watches a User List and fires your workflow whenever rows are added, updated, or deleted.

No polling, no manual kicks, no cron jobs guessing when data changes.

What Is the List Change Trigger?

The List Change Trigger is a new node type in the Triggers category of the left sidebar. Drag it onto your canvas, pick which list to watch and which operations matter to you, click Run Test, and you are done.

From that moment on, whenever the watched list changes — through the UI, through the User Lists worker in another workflow, or through the API — your workflow fires automatically with the updated data passed in as context variables.

Reactive, Not Polling

Under the hood, list mutations publish events to a Redis Stream, and a background listener picks them up using XREAD BLOCK — the same efficient mechanism used by message queues. There is no polling, no wasted compute, and near-zero latency (typically under 5 seconds).

Key Features

• List autocomplete — start typing your list name and the dropdown finds it instantly
• Multi-select trigger operations — choose exactly which changes matter: add_row, update_rows, delete_row, or any combination
• Optional DSL filter — only fire the workflow when rows matching a condition are affected (e.g. only when status eq active AND price gt 100)
• Pass list data — toggle to include the full list rows in the context variables so downstream workers can process them immediately
• Operation filtering — if you only care about updates, the trigger ignores adds and deletes

How to Use It

Finding the Worker

Look in the Triggers category in the left sidebar, or search for "list change". The node has a 📋 icon with a pulse indicator showing it monitors for changes.

Adding to Your Workflow

1. Drag the List Change Trigger node onto the canvas
2. Connect it to the rest of your workflow nodes
3. Configure — click the node to open the right panel

Configuration

Parameter	What It Does
List to watch	Autocomplete — search and select any User List you own
Trigger on	Checkboxes: add_row, update_rows, delete_row. Pick one or more
DSL Filter	Optional expression like status eq active — workflow only fires if matching rows exist
Pass list data	Toggle — when on, the full list rows are available as trigger.listData in context variables

Run Test

Click Run Test on the trigger node. This saves the configuration and returns:

• Status — active if everything is set up correctly
• List name — confirmation of which list is being watched
• Trigger operations — which changes will fire the workflow
• Row count — how many rows the list currently has

Once saved, the trigger is live — any matching change to that list will start a workflow run.

Context Variables

The following variables are available in downstream nodes when the trigger fires:

Variable	Description	Example
trigger.listId	The MongoDB ID of the list	"6a3813519ddc3a467466c561"
trigger.listName	The display name of the list	"Trading Journal Q2"
trigger.operation	What happened	"update_rows"
trigger.listData	Current rows (array of objects)	[{symbol: "AAPL", price: 190}]
trigger.matchedRows	(if filter set) Only the rows that matched	filtered subset

Use Cases

Reactive Trading Journal

When you update a trade's P&L in your journal list, the workflow recalculates performance metrics, updates a dashboard widget, and sends a Telegram summary.

[Journal List Update] → [List Change Trigger]
  → [Calculate Metrics] → [Update Dashboard] → [Send Summary]

Watchlist Price Monitor

A market data worker periodically updates prices in a watchlist. Every time a price changes, the List Change Trigger fires a workflow that checks for breakout signals, evaluates risk, and alerts you.

[Price Updater Worker] → [Update Watchlist] → [List Change Trigger]
  → [Check Breakouts] → [Evaluate Risk] → [Send Alert]

Multi-Step Data Pipeline

A data collection workflow adds rows to a source list. The List Change Trigger detects the new rows and kicks off a processing pipeline — enriching, analyzing, and storing results in another list.

[Data Collection] → [Add Rows to Source List] → [List Change Trigger]
  → [Enrich Data] → [AI Analysis] → [Store in Result List]

Approval Workflow

A team member adds a row with status: "pending_approval" to a shared list. The trigger fires, the workflow checks the DSL filter (status eq pending_approval), runs validation, and sends a Slack or email notification to the approver.

[List Change] → [DSL Filter: status eq pending_approval] → [Validate]
  → [Notify Approver via Telegram/Slack]

Audit Trail

Track every change to critical lists. The trigger fires on every operation, logs the change to a second list or MongoDB collection, and keeps a full audit history.

[Any List Change] → [List Change Trigger] → [Log to Audit List]
  → [Alert on Suspicious Changes]

Workflow Patterns

Single-Trigger Standalone

The simplest setup: one trigger, one workflow. Good for simple reactions.

[List Change] → [List Change Trigger] → [Process Data] → [Output]

Chained Triggers

Multiple workflows can watch the same list with different filters. Workflow A handles add_row for new entries, Workflow B handles status eq active updates only.

[Same List]
  ├─ [Trigger A: add_row] → [New Entry Handler]
  └─ [Trigger B: update_rows + DSL filter] → [Active Item Processor]

Hybrid Timed + Reactive

Use the Schedule Trigger for periodic maintenance runs and the List Change Trigger for immediate reactions. Both point to shared downstream logic.

[Schedule Trigger (hourly)] → [Shared Logic: Validate → Clean → Report]
[List Change Trigger (instant)] → [Shared Logic: Validate → Clean → Report]

Parameter Loop + List Change

A Parameter Loop worker generates multiple configurations and stores them in a list. Each new row triggers a separate workflow run that backtests that configuration.

[Parameter Loop] → [Add Row to Config List] → [List Change Trigger (per row)]
  → [Backtest Config] → [Store Results]

Best Practices

• Be specific with operations — if you only care about updates, uncheck add_row and delete_row. This keeps your workflows focused and avoids unnecessary runs.
• Use DSL filters for large lists — if your list has hundreds of rows but you only care about rows with status eq active, set the filter. The triggered workflow receives matchedRows — only the relevant subset.
• One trigger per (workflow, list) pair — you can have multiple workflows watching the same list, but only one trigger per workflow-list combination.
• Pass list data — keep this enabled unless your list is extremely large. It saves a DB round-trip in downstream workers.
• Test with Run Test — the "Run Test" button saves the trigger config and returns a summary. Make a change to the list and your workflow should fire within seconds.

How It Works (Architecture)

User List Mutation (UI / Worker / API)
  → publish_list_change_event()
  → XADD to Redis Stream "apudflow:stream:list-change-events"
  → Listener (XREAD BLOCK, 5s timeout)
  → Find matching subscriptions in MongoDB
  → Check triggerOn matches operation
  → Evaluate DSL filter (if set)
  → Create workflow run with context vars
  → Push to workflow queue
  → Executor picks up and runs the workflow

The entire pipeline is asynchronous and event-driven. There is no blocking, no polling, and no performance impact on the list mutation itself.

Legal Disclaimer

This is not financial advice. Trading involves significant risk of loss. Use reactive workflows at your own discretion.