Core concepts

The mental model behind every Flero workflow. Once these five concepts click, the rest of the platform follows from them.

📸 Screenshot needed: concepts__model-diagram.png, clean diagram showing a workflow as nodes connected by edges, with one trigger node highlighted, ports labelled, and an expression callout pointing to a field on a downstream node.

1. Workflows

A workflow is a directed acyclic graph (DAG) of nodes connected by edges. One node is the trigger, it decides when the workflow runs. Every other node is an action that executes when data reaches it.

Workflow properties

Property	Description
Name	Display name; used in expressions to reference nodes inside the workflow. Rename safely.
Description	Free text. Show up to the workflow card on `/workflows`.
Status	One of `draft`, `active`, `inactive`, `archived` (see lifecycle below).
Tags	Free-form labels for organisation and search.
Version	Semantic version string. New saves create a new version; you can roll back from the toolbar's history dropdown.
Owner	The user who created the workflow.
Shared with	A list of users with explicit access if the workflow isn't team-wide.

Workflow lifecycle

draft  ←→  active  ←→  inactive  →  archived (30-day retention)

Draft, Default state for new and unsaved workflows. Triggers are disabled. Run manually for testing.
Active, Triggers are armed; webhooks accept POSTs, schedules fire, connector events route here. Production state.
Inactive, Triggers are disabled but the workflow is still visible and runnable manually. Use this to pause production.
Archived, Hidden from the default list. Retained 30 days, then permanently deleted. Restore from the Archive tab at any time.

2. Nodes

A node is a single step in the workflow. Each node has:

A type (e.g. HTTPRequest, If, AIAgent), chosen from the palette.
A display name, what shows on the canvas and what expressions use to reference it.
Configuration, fields specific to the type (URL, method, condition, prompt, …).
Input ports, connection points where data arrives.
Output ports, connection points where data leaves. Most nodes have one (output); conditional nodes have multiple (e.g. If has true and false; Switch has named cases; Loop has loop and done).

Node categories

Category	Examples	Purpose
Triggers	Webhook, Schedule, Form, Manual (Start), Chat	Start a workflow
Flow control	If, Switch, Loop, Merge, Delay, Approval, Error handling	Shape the path
Data transformation	Transform, Code, Text, DateTime, Encryption, File, PDF, Image	Reshape data
HTTP & API	HTTP Request, Webhook API, Web Scraper, Pagination	Talk to external services
Storage	Database, Set (variables), Cache	Persist data
AI & LLM	AI Agent, Prompt Template, AI Eval, Guardrails, Semantic Router	Run LLM steps
RAG	Document Chunker, Embeddings, Vector DB, Reranker	Retrieval pipelines
Communication	Email, Notification, Real-time	Send messages
Utility & debugging	Log, Debug, Terminal, Set	Observe and end
Enterprise connectors	Slack, Salesforce, AWS, Google Workspace, … (40+)	Pre-built service integrations
Sub-workflows	Sub-workflow node	Compose larger automations

The full list is in Section 03, Nodes.

3. Connections

A connection is a line drawn from one node's output port to another node's input port. Connections define data flow.

Rules:

Output → input only. (You can't connect input to input.)
One output can fan out to many inputs.
Many outputs can fan into one input (use a Merge node to combine them deliberately).
No cycles. A workflow is a DAG.
The data the source node emits on that output port arrives at the destination node's input port as-is.

📸 Screenshot needed: concepts__port-anatomy.png, close-up of two nodes with their input/output ports labelled, plus an If node showing its two output ports (true/false).

4. Expressions

Expressions are how downstream nodes use data from upstream nodes. Anywhere you can type a value into a config field, you can type an expression instead.

The syntax

{{ $node["HTTP Request"].json.body.email }}

{{ }}, opens and closes the expression.
$node["…"], looks up another node by its display name (case-sensitive).
.json.<path>, navigates into that node's output. .output.<path> is a synonym.
The whole thing is replaced with the resolved value at runtime.

What else you can reference

Reference	What it returns
`$node["Name"]`	The full output object of that node
`$trigger`	The data that started this run (webhook payload, schedule metadata, form fields)
`$workflow`	Workflow metadata (`id`, `name`, `version`, `settings`, `metadata`)
`$env.VAR`	A workspace-level environment variable
`$input`	The data currently entering the node

Mixing literal text and expressions

You can combine them freely:

https://{{ $env.API_HOST }}/users/{{ $trigger.body.userId }}/orders

Errors

If the lookup fails (typo in the node name, missing field, etc.), Flero replaces the expression with a marker like [EXPR-ERROR: Node "HTTP Reqest" not found. Available: [HTTP Request, Log]] so the typo is visible in the output. The full language is in Section 04, Expressions.

5. Executions

An execution is one run of a workflow. It has:

A unique execution ID.
A status:
- pending, queued, waiting for a worker
- running, in flight
- success, completed cleanly
- failed, a node threw and wasn't caught
- cancelled, manually stopped
- timeout, exceeded the time budget
- waitingForInput, paused for an approval or user input
An input (what the trigger received).
A per-node timeline, duration, input, output, errors for every node that ran.
An output (what the terminal node returned, if any).

Executions are persisted to your workspace's execution history (default: 30 days). You can search every execution from /logs and drill in via /logs/:id. See Section 07, Running & monitoring.

Execution lifecycle

[Trigger fires]
      ↓
   pending  ←  queued in RabbitMQ
      ↓
   running  ←  worker picks it up; executes nodes one at a time
      ↓
[ success | failed | cancelled | timeout | waitingForInput ]
                                                    ↓
                                                resume → running → success/failed/…

A workflow paused for approval stays in waitingForInput until someone responds; the run picks up exactly where it left off and continues.

How the five fit together

[Trigger]──→[Action]──→[Action]──→[Action]
   │           │
   └─ starts   └─ uses expressions to read from upstream nodes
      a NEW       and from the trigger payload
      EXECUTION

That's the whole model. Everything else, connectors, approvals, sandbox mode, sub-workflows, is built on top of these five primitives.

Your first workflow, see the model in action
Expressions, the $ language in depth
Running & monitoring, what to do with executions

Found something out of date? This page lives in the Flero docs content set.