Visual Builder
Execution
Run any workflow directly from the builder and watch it execute node by node, in real time.
Entry points
A workflow starts from one or more entry nodes — an API Endpoint, a Webhook, or an Execute node used for manual or scheduled runs. When several entry points coexist in the same workflow, the Execute node's execution order setting decides which one runs first.
Running a workflow
Press Run from the builder toolbar. Fimaflow walks the graph following the edges, highlighting each node as it executes so you can follow the request as it flows through your backend — no separate terminal or log viewer needed.
- • Nodes light up as they run, in execution order.
- • A failed node is highlighted immediately, without waiting for the rest of the graph.
- • Every run produces logs you can inspect afterward — see Debugging.
How data flows between nodes
Each node receives the output of the node connected to its input, and produces its own output for the next one. Anywhere a node accepts a text value, you can reference data from earlier in the run with {{variableName}} — resolved from the workflow's variables (see Environment Variables) or from the incoming input, in that order.
Execution history
Every run is recorded — status, start and end time, and the full log trail — whether it was triggered manually from the builder or by a live request once the workflow is exported and deployed. Past runs stay available so you can compare behavior over time or replay what happened during an incident.
Example: running "Create Order"
Take the four-node workflow from Workflows and press Run with a sample request body. Here's what the live view shows, node by node:
1. API Endpoint ✓ received { "sku": "TSHIRT-M", "qty": 2 }
2. Validation ✓ body matches schema
3. SQL ✓ INSERT INTO orders — 1 row, 12ms
4. Response ✓ 201 { "orderId": "ord_8f21" }
Run finished in 41ms — 4/4 nodes succeededIf the SQL node had failed instead — say, a missing database connection — step 4 would never run, and the highlighted failure would point straight at step 3. See Debugging for that exact scenario.