One post tagged with "sub-workflow"

You've built a library of workflows — data pipelines, signal generators, backtesters, alert senders. Until now, each one ran in isolation. The new Run Workflow worker changes that: trigger any workflow from inside another workflow, pass variables between them, and (optionally) wait for results.

This turns your workflows into reusable building blocks — your data-processing workflow becomes a function call, your backtest runner becomes a sub-process, your entire analysis chain becomes a single parent workflow.

What Is the Run Workflow Worker?​

The Run Workflow worker lives in the Flow category of the left sidebar. Drag it onto your canvas, select a target workflow (via autocomplete), optionally pass variables, and choose a mode. That's it.

It's a flow-control node — it orchestrates other workflows rather than processing data itself.

Key Features​

• Autocomplete target selection — search and pick any of your workflows by name
• Variable passing — send key-value data that becomes available in the target workflow as {{ variable }}
• Two execution modes — fire-and-forget for parallel execution, wait-for-result for sequential chaining
• Timeout control — in wait mode, configure how long to wait (10–600 seconds)
• Full result capture — wait mode returns every node's output from the target workflow

How to Use It​

Finding the Worker​

Look in the Flow category in the left sidebar, or search for "run workflow". The node shows a play-arrow icon with a gear.

Adding to Your Workflow​

1. Drag the Run Workflow node from the left sidebar onto your canvas
2. Connect it to preceding nodes (e.g., a trigger or data source)
3. Click the node — the right panel opens with configuration fields
4. Select target workflow — the autocomplete field lets you search by name

Configuration​

Passing Variables​

Any variables you pass become available in the target workflow's context. For example, if you pass:

{
  "symbol": "BTCUSD",
  "timeframe": "1h",
  "limit": 200
}

The target workflow can reference them as {{ symbol }}, {{ timeframe }}, and {{ limit }} in any downstream node — just like webhook trigger variables.

Mode Comparison​

Workflow Chaining Patterns​

1. Simple Trigger Chain (Fire-and-Forget)​

[Manual Trigger] → [Run Workflow "Fetch Data"] → [Run Workflow "Send Alert"]

The parent workflow triggers "Fetch Data" and "Send Alert" — both run independently.

2. Data Pipeline (Wait-for-Result)​

[Schedule Trigger] → [Run Workflow "Fetch & Clean Data" (wait)] → [Run Workflow "Generate Signals" (wait)] → [Run Workflow "Store Results"]

Each step waits for the previous one to finish. The parent orchestrates a multi-stage pipeline.

3. Fan-Out / Parallel Processing​

[Trigger] → [Run Workflow "Analyze BTC" (fire-and-forget)]
         → [Run Workflow "Analyze ETH" (fire-and-forget)]
         → [Run Workflow "Analyze SOL" (fire-and-forget)]

All three analysis workflows launch simultaneously — great for multi-symbol scans.

4. Reusable Report Generator​

[Webhook Trigger] → [Fetch Data] → [Process Signals] → [Run Workflow "Generate Report" (wait)] → [Telegram Notify]

The "Generate Report" workflow is shared across many parent workflows — write once, reuse everywhere.

Financial Markets Applications​

Strategy Pipeline​

[Schedule Trigger] → [Run Workflow "Fetch OHLCV Data" (wait)]
                   → [Run Workflow "Compute Indicators" (wait)]
                   → [Run Workflow "Run Backtest" (wait)]
                   → [Telegram Send Results]

Chain your data-fetching, indicator, and backtest workflows together. Each is independently testable and reusable.

Multi-Symbol Analysis​

[Trigger] → [Parameter Loop] → [Run Workflow "Analyze Symbol"]

Use a Parameter Loop to iterate over symbols, passing each one to a shared analysis workflow via variables. Collect results in a final aggregation step.

Output​

Fire-and-Forget​

• run_id — the ID of the triggered run (use to track progress)
• targetWorkflowName — name of the triggered workflow
• passedVariables — the variables that were passed along

Wait-for-Result (all of the above, plus)​

• targetStatus — finished, failed, error, or cancelled
• targetResults — object mapping each node name to its output
• targetFinishedAt — timestamp of completion

Tips​

• Name your workflows clearly — the autocomplete shows workflow names. Descriptive names make selection faster.
• Use wait mode for dependencies — if step B needs step A's output, use wait-for-result.
• Use fire-and-forget for independence — if steps don't depend on each other, let them run in parallel.
• Watch timeouts — complex target workflows may need more than 300s. Adjust the timeout parameter in expert settings.
• Variable names matter — pass variables with names that match what the target workflow expects.

Legal Disclaimer​

This is not financial advice. Trading involves risk of financial loss. The Run Workflow worker is a tool for automation — you are responsible for the logic and outcomes of your workflows.