> For the complete documentation index, see [llms.txt](https://docs.openalgo.in/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openalgo.in/new-features/flow-visual-strategy-builder.md).

# Flow - Visual Strategy Builder

Flow is OpenAlgo's visual workflow editor and synchronous execution engine. A workflow is a directed graph with exactly one trigger and a reachable chain of data, condition, trading, streaming, and notification nodes.

## Current Capabilities

* 61 node types kept in parity across the editor, backend validator, executor, and tests.
* Four triggers: Schedule, Price Alert, Webhook, and Order Update.
* Regular, smart, options, basket, split, modify, cancel, and close-position actions.
* Quote, depth, history, indicator, account, options, and calendar data nodes.
* Branch conditions and AND/OR/NOT gates.
* LTP/Quote/Depth subscriptions, logging, variables, math, HTTP requests, delays, wait-until, Telegram, and WhatsApp actions.
* Strategy-level realized/unrealized P\&L.
* JSON import, export, and validated in-place replacement.
* Execution history and per-node logs.

Flow does not provide loops, foreach/switch nodes, cross-run variables, automatic retry/error-handler nodes, built-in backtesting, or version-control history.

## Build a Workflow

1. Open `/flow` and create a workflow.
2. Drag one trigger onto the canvas.
3. Add downstream nodes and connect them in execution order.
4. Configure each node. Give a producer an `outputVariable` when a later node needs its result.
5. Branch from conditions using the `true`/`false` or `yes`/`no` handles.
6. Save while editing. Incomplete graphs may be saved, but corrupt node types, duplicate IDs, and dangling edges are rejected.
7. Use **Run Now** to validate and test a complete graph.
8. Activate the workflow when its trigger should remain registered.

## Trigger Types

| Trigger                             | Behavior                                                    | Important configuration                                                                                                             |
| ----------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Schedule (`start`)                  | Once, daily, weekly, or interval execution                  | IST time/day values and an optional market-hours gate driven by the exchange calendar, with optional exchange and `HH:MM` overrides |
| Price Alert (`priceAlert`)          | Watches LTP for a level, cross, channel, or percentage move | Symbol/exchange, thresholds, once/every-time, expiration                                                                            |
| Webhook (`webhookTrigger`)          | Executes from a tokenized public POST                       | Optional symbol filter and payload or URL-secret authentication                                                                     |
| Order Update (`orderUpdateTrigger`) | Executes on normalized live/sandbox order state             | Order ID or symbol filter, optional exchange/status, once/every-time                                                                |

Every complete workflow must contain exactly one trigger. Multiple triggers, cycles, unreachable executable nodes, invalid edges, missing required fields, and oversized graphs are rejected before a broker call.

## Variables

Use `{{path}}` inside string fields:

```
{{quote.data.ltp}}
{{chain.data.results[0].ce.ltp}}
{{webhook.symbol}}
{{timestamp}}
{{session_date}}
```

Dotted dictionary keys and non-negative list indexes are supported. Most missing paths remain literal in the rendered string so the execution log exposes the mistake. A Variable Condition is stricter: an unresolved operand takes neither branch.

## Example: Signal to Order

```
Webhook Trigger -> Place Order -> Telegram Alert
```

Configure order fields with payload values such as `{{webhook.symbol}}`, `{{webhook.action}}`, and `{{webhook.quantity}}`. Give the order an output variable such as `order`, then notify with `{{order.orderid}}`.

Webhook URLs are:

```
POST /flow/webhook/<token>
POST /flow/webhook/<token>/<symbol>
```

Tokens and secrets are generated by the server. Use HTTPS for an internet-facing webhook.

## Import, Export, and Replace

Imported JSON uses this top-level shape:

```json
{"name": "Example", "nodes": [], "edges": []}
```

Import creates a new workflow. **Replace from JSON** changes the graph of an existing workflow while preserving its ID, webhook token/secret, API key, and active flag. If active trigger configuration changes, deactivate and reactivate the workflow so the trigger is registered again.

See [Flow Editor](/flow-editor/flow-editor.md) for the execution model, complete node reference, import behavior, tested tutorials, and current limitations.

## Execution and Safety

* One per-workflow lock prevents overlapping executions of the same workflow.
* A graph is limited to 500 nodes, 1000 edges, depth 100, and 500 total node visits.
* Schedule jobs use `coalesce=true`, `max_instances=1`, and a 60-second misfire grace.
* Active price and order-update watches are removed on deactivation/deletion and restored after restart when persisted configuration permits it.
* Order nodes use the same service layer and Analyzer/semi-auto routing rules as the REST API.
* Delay nodes and external broker/HTTP calls keep execution synchronous; avoid long waits across many active workflows. A `delay` node is capped at 300 seconds, while `waitUntil` is uncapped and holds the workflow lock for its full duration.
