Skip to content

Core concepts

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

A workflow in the editor: an API/Webhook trigger feeds an HTTP Request, then an If node that branches to an Email node and a Log node. The Email node's panel is open, with expressions in its Subject and Body fields.A workflow in the editor: an API/Webhook trigger feeds an HTTP Request, then an If node that branches to an Email node and a Log node. The Email node's panel is open, with expressions in its Subject and Body fields.

1. Workflows

A workflow is a graph of nodes joined by connections, owned by one workspace. A trigger node decides when it runs. Every other node is a step that runs when data reaches it.

Workflow properties

Property Description
Name Display name. Rename it by double-clicking the name in the editor.
Description Optional free text, shown on the workflow card.
Status draft (the default for new workflows), active, inactive or archived.
Versions Every save that changes the workflow creates a numbered version (V1, V2, …). One version can be the active one.
Variables Workflow variables, set in Workflow settings → Variables and read as {{ $workflow.variables.name }}.
Folder Optional, for organising the Workflows page.

Status and active versions

Status What it means
Draft Saved but never activated.
Active Automatic triggers (webhook, schedule, connector events) run its active version.
Inactive Automatic triggers are off. You can still run it by hand.
Archived Moved to the Archive tab. Restore it from there. Archived workflows can be deleted permanently after 30 days.

A draft becomes active when you activate a version, and you can switch between active and inactive at any time. A workflow in any status can be archived.

  • Draft: new workflows start here. You can build and run them from the editor.
  • Active: automatic triggers are on. Schedules fire, webhooks accept requests, connector events start runs.
  • Inactive: automatic triggers are off. You can still open and run the workflow from the editor. Use this to pause a workflow in production.
  • Archived: hidden from the main list. Restore it from the Archive tab, or it is deleted after 30 days. See Archive and restore.

Automatic triggers run the workflow's active version, not your latest edits. A workflow needs both: status active and an active version. See Versions and activation.

2. Nodes

A node is one step in the workflow. Each node has:

  • A type, chosen from the palette (HTTP Request, If, AI Agent, …).
  • A name, unique within the workflow. It shows on the canvas, and expressions use it to refer to the node. New nodes take the type's name, then HTTP Request 2, HTTP Request 3, and so on.
  • Configuration: the fields for that type (URL, method, condition, prompt, …), plus Node Settings for error handling and timeout.
  • Input ports, where data arrives.
  • Output ports, where data leaves. Most nodes have one. Branching nodes have several, for example If has true and false. Some nodes also have an error port that receives a failure instead of stopping the run.

Palette groups

Group Examples Purpose
Triggers Start, Scheduler, API/Webhook Trigger, Form Trigger, Chat Start a workflow
AI AI Agent, Embeddings Run AI steps
Flow Control If, Switch, Loop, Merge, Sub-Workflow, Approval Shape the path
Developer Tools Code, Log, Delay Custom logic and debugging
Integrations Slack, Salesforce, HubSpot, Google Workspace, … Pre-built connectors to business platforms
Data Storage Set, Data Transform, Database Reshape and store data
Communication HTTP Request, Email, Notification Call APIs and send messages

The full list is in Nodes.

3. Connections

A connection joins one node's output port to another node's input port. Connections define how data flows.

  • Connections always run from an output to an input.
  • One output can feed many nodes (fan-out). Each receives the same data.
  • Many connections can feed one node (fan-in). The node receives the combined upstream data. Use a Merge node when you need to control how inputs combine.
  • Branching nodes send data down only the port they choose, for example true or false on an If node. Nodes on the other branch don't run.
  • To repeat steps, use a Loop node.
Close-up of an HTTP Request node connected into a selected If node, showing the If node's input port on the left and its True and False output ports on the right, each wired to a different node.Close-up of an HTTP Request node connected into a selected If node, showing the If node's input port on the left and its True and False output ports on the right, each wired to a different node.

4. Expressions

Expressions put values from earlier nodes, the trigger, variables or workflow details into a node's fields. Anywhere you can type a value, you can type an expression.

The syntax

{{ $node["HTTP Request"].output.response.body.email }}
  • {{ }} opens and closes the expression.
  • $node["…"] looks up another node by its name (case-sensitive). Single quotes work too.
  • .output.<path> goes into that node's output. .json.<path> means the same thing.
  • When the node runs, the whole expression is replaced with the value it finds.

What else you can reference

Reference What it returns
$node["Name"] The output of the node with that name
$trigger The data that started the run. For example $trigger.payload.email. Webhooks also expose headers, query, method and path.
$input The data arriving at the current node
$env.NAME A workspace variable
$workflow Workflow details: id, name, and variables.NAME

Paths support nested fields (.a.b) and list items (.items[0]).

Mixing text and expressions

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

Expressions look values up, nothing more

Expressions don't run functions (upper(...), now()), arithmetic (+), comparisons or method calls (.length). Do that work in a Set, Data Transform or Code node, then reference its output. Condition nodes such as If have their own condition settings.

Errors

If a lookup fails (a typo in a node name, or a path through a missing value), Flero replaces the expression with a visible marker such as [EXPR-ERROR: Node "HTTP Reqest" not found …]. A reference to a workspace variable that isn't set fails the node instead. The full language is in Expressions.

5. Executions

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

  • A unique execution ID.
  • A status:
    • pending: queued, waiting to start
    • running: in progress
    • paused: paused by a person
    • waiting_for_input: parked at an approval or form step until someone responds
    • success: finished cleanly
    • failed: a node failed and nothing handled it, or the run stopped responding
    • timeout: ran out of time
    • stopped: stopped by a person
  • The version of the workflow that ran.
  • A per-node record: duration, input, output and errors for every node that ran.

Every run is kept in your execution history. Search them in Logs and open one at /logs/<id>. See Execution lifecycle.

How a run moves

  1. A trigger fires, or you click Run. The run is created as pending.
  2. A worker picks it up and the run becomes running. Nodes run one after another along the connections.
  3. The run ends as success, failed, timeout or stopped.
  4. A run can also pause (paused) or wait for a decision (waiting_for_input, waiting_for_human). When it resumes, it goes back to running.

A run waiting for an approval keeps its place. When someone responds, it continues from where it stopped.

How the five fit together

Workflow: New order to Get customer, Get customer to Build message, Build message to Post to #orders New orderAPI/Webhook Trigger Get customerHTTP RequestBuild messageSet Post to #ordersSlack

The trigger starts a new execution. Each node after it uses expressions to read from earlier nodes and from the trigger data.

That's the whole model. Everything else, from connectors and approvals to sandbox mode and sub-workflows, is built on these five ideas.

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