Node reference

Trigger

Where every run starts. Each workflow has exactly one. Types: Manual (the Run button), Scheduled (one-time, daily, weekly, monthly or a cron expression, in a timezone you choose), Webhook (a fixed URL your systems can POST to) and App event (a new item in a connected app — a sheet row, a HubSpot contact, a Slack message — checked on your plan's schedule interval, or delivered instantly by a signed webhook for apps that support it).

When to use

• Manual — prototyping and one-off jobs someone kicks off.
• Scheduled — daily digests, weekly reports, regular polling.
• Webhook — reacting to events from another system or starting a workflow from your own backend.

Common errors

• Scheduled or webhook trigger does nothing — it hasn't been activated. Press Activate schedule / Activate webhook in the Activation panel at the top of the trigger's settings.
• Webhook returns 403 — the secret header or signature is missing or wrong, or the webhook is switched off.
• Schedule rejected — it repeats faster than your plan allows.

Action

Does something. Kinds: AI Generate (an AI prompt using your provider key), HTTP Request, Webhook Call, Send Email and Slack Post. HTTP-style actions support headers, templated bodies and a vault credential. Retries are configurable (exponential, fixed or none).

When to use

• Call an external API with a templated body.
• Generate text with AI as one step in a workflow.
• Send an email or Slack message as part of a workflow.

Common errors

• The external API returned an error — check the Trace tab for the status and response, and the provider's status page.
• The credential can't be found — it was archived. Pick another credential in the node's settings.
• No AI provider connected (AI Generate) — connect one in Settings → AI Providers.

Agent

An AI step that can take several reasoning steps before answering. Configure the model, temperature, max tokens, max steps, system and user prompts, an optional output schema, and the tools it may use. The built-in tool today is an HTTP request tool. Calls run on your workspace's own AI provider key.

When to use

• Summarising, classifying, drafting or extracting information.
• Tasks where the model should look something up over HTTP before answering.
• Follow it with a Validator when the output must have a fixed shape.

Common errors

• No AI provider connected — add one in Settings → AI Providers.
• Key rejected or out of credit — fix the key or billing with your provider, then press Test in Settings → AI Providers.
• Rate limited — wait and retry, or raise your usage tier with the provider.

Transformer

Reshapes data without side effects. Modes: mapping (map fields or set constants), template, normalise contact, and API payload.

When to use

• Renaming fields between one step's output and the next step's input.
• Building a clean payload before an HTTP Request.
• Normalising contact details (names, emails, phone numbers).

Router

Branches the run. Each route has one or more conditions (equals, not equals, greater/less than, contains, exists, empty and so on) combined with AND or OR. The run follows the first route that matches; if none match it follows the default route.

When to use

• Split flows by status, plan, amount or any field.
• Send high-risk items to a Human Review step and the rest straight through.

Common errors

• The run went down the default route unexpectedly — check the field paths in your conditions against the Inspector tab's input for the Router.

Validator

Checks data against rules (equals, comparisons, includes, starts/ends with, regex match, exists, type checks) or a JSON schema, and sends the run down its pass or fail branch.

When to use

• Right after an AI step, to make sure required fields are present.
• Before a high-risk action (sending email, charging a customer).
• On webhook payloads that other systems might send malformed.

Guardrail

A policy check on the data passing through. Set banned terms and blocked fields, a severity, and whether a match should block the run or only warn.

When to use

• Stopping AI output that contains words or data you never want sent.
• Blocking fields (for example internal notes) from reaching an outbound step.

Run-wide limits are built in: every server run stops after about 50 seconds or $2 of estimated AI cost.

Retriever

Looks up the most relevant entries from workflow memory (written by a Memory node) or from static data you provide, using keyword matching. Set how many results to return (top K) and a minimum score, then feed them to an AI step.

When to use

• Giving an AI step relevant notes or reference text to ground its answer.
• Lookup-then-decide flows — fetch matching entries, then a Router picks what to do.

Memory

Stores and reads values by namespace and key, with an optional time-to-live. Choose persistent storage to keep values across runs, or ephemeral to keep them for the current run only.

• Operations: write (store a value), read (get it back), delete (forget one key) and clear (forget a whole namespace).
• Persistent memory belongs to the workspace, not to one workflow: two workflows that use the same namespace and key share the value, so give each workflow its own namespace.
• The key and a written value can use references such as {{trigger.from}}, {{steps.<step>.<field>}} or {{input.<field>}} — for example one entry per contact, keyed on their phone number or email. A key that comes out empty fails the step.
• A written value that is JSON text is stored as JSON (lists and objects keep their shape); other text is stored as text.
• A read returns hit (true or false) and value — the stored value, or your fallback value (or nothing) when the key isn't there or has expired. Later steps read it as {{steps.<memory step>.value}}.
• TTL (seconds): how long a written value is kept; 0 keeps it until it's deleted. Writing again replaces the value and restarts the timer — unless Allow overwrite is off, in which case an existing value is kept.
• Dry Run never reads or writes stored memory: a read finds nothing and a write only shows what it would store.

When to use

• Avoiding duplicates — record an ID after handling an event so the next run can skip it.
• Remembering a cursor or last-seen timestamp between scheduled runs.
• Counters that carry across runs.

Human Review

Pauses a real run until someone approves or rejects it in the Review Queue. Set the prompt the reviewer sees, a priority, an optional assignee and an optional timeout. The run continues down the approved or rejected branch, or the timeout branch if nobody decides in time. In a Dry Run you pick which decision to simulate.

When to use

• Approving outbound messages an AI step drafted.
• Reviewing flagged transactions before they're processed.
• Checking contracts or documents before they're sent.

Common errors

• Run waiting a long time — open the Review Queue and decide, or reassign it to someone available.
• Reviewer wasn't alerted — review alerts go to the notification bell of everyone who can review (Support Agent role and above). There are no email alerts for reviews yet.

Integration

App action mode: pick an app, a connected account (or connect one right there) and an action, then fill in the form — channels, sheets, databases and pipelines load from your account. Use {{input.field}} in any box to insert data from earlier steps. Dry Run never contacts the app: it shows a simulated output. Send test request (after a confirmation) makes one real call. Custom request mode is the original step: method, URL, headers, body, authentication (a connected account or a vault credential), timeout and retries. Requests to private or local network addresses are blocked.

When to use

• Posting to Slack, adding or finding Google Sheets rows, creating HubSpot contacts and deals, creating Notion pages, creating Salesforce records or running SOQL queries — or calling any API with Custom request.

Newer app actions

• Google Sheets → Update a row: overwrites cells in one row from a start column (for example mark a row done), leaving the other cells as they are. The row number comes from Find a row (row_number) or a row's _row from Read rows.
• Notion → Read a page's text: reads a page's paragraphs, headings, lists, to-dos, quotes, callouts and code as plain text (for example a policy page for an AI step). Only top-level blocks: text inside toggles or sub-lists isn't included. The page must be shared with the Fluxo Flow connection.
• Slack → Read recent channel messages: a channel's recent messages, oldest first (thread replies not included). Since takes hours (24), days (7d) or a date; up to 200 messages. The Fluxo Flow app must be in the channel.
• Stripe → List refunds (beta): recent refunds, newest first, optionally only those created in the last N hours or for one payment.
• Greenhouse → Add a note to a candidate and Read a candidate's activity feed (beta).
• HTTP / Custom API connection: besides a bearer token, an API key in a header and Basic auth, it supports an API key in a query parameter (you name the parameter, for example api_key). The key is stored encrypted and hidden in run history.

Observer

An AI step that reviews the run so far — errors, performance and cost — and produces insights. It uses your AI provider key and has its own model, max tokens and max cost settings. It doesn't change the data flowing through the workflow.

When to use

• Getting an automatic write-up of what went wrong or what was slow in a run.

For each item

Repeats a group of steps once per item of a list, then continues once with all the results. Set the list to repeat over with a reference — for example {{steps.<read rows step>.rows}} or {{trigger.items}}. Workflows can't contain cycles, so this is how you repeat steps.

• Two outputs: the steps connected to "each item" run once per item; the steps connected to "done" run once afterwards.
• Inside the loop, steps read the current item as {{item}} or {{item.<field>}}, and its position as {{loop.index}} (from 0), {{loop.number}} (from 1), {{loop.count}}, {{loop.first}} and {{loop.last}}. They can also read any step before the loop and earlier loop steps for the same item with {{steps.…}}.
• After the loop, "done" gets results (the last loop step's output for each item, empty for a failed item), items (each item with its status, output and error), count, successCount and errorCount — also readable later as {{steps.<loop step>.results}}.
• Max items per run: 50 by default, at most 500. Items past the cap are left out of this run. Dry Run repeats only the first 3 items.
• When an item fails: "Record it and go on" (default) or "Stop the loop", which fails the loop — connect its error output to handle that.
• Not allowed inside a loop: a Wait, a Human Review or another For each. Steps outside the loop can't connect into it; continue from "done" instead.

Wait

Pauses a live run and continues it later. Choose "For a while" (an amount of minutes, hours or days) or "Until a date" (a date taken from the data, such as {{steps.<step>.json.followUpAt}} — an ISO date or a Unix timestamp). A Wait can pause a run for at most 30 days; a date that has already passed doesn't wait.

• Business days only: days count Monday to Friday, and a resume time on a weekend moves to Monday (same time). Weekends are judged in the time zone you pick (UTC by default).
• While a run waits, nothing runs and no run time is used. Waits are checked every minute, and the run continues on its own after the Wait step.
• History shows the run as "Waiting until …"; the API reports it as paused with a wait object (step, resume time). A waiting run can be cancelled with POST /api/v1/runs/{id}/cancel — it then never resumes.
• The step after the Wait gets the same input the Wait received, and {{steps.…}} and {{trigger.…}} still work after the pause.
• Dry Run doesn't wait: the step shows how long it would wait and the run goes on.
• Not allowed inside a For each item loop. Live runs need a paid plan, so a waiting run on the Free plan doesn't resume.

Loop (whole list)

Passes a whole list on at once (from a path in the incoming data, up to a maximum number of items), or runs another workflow once per item. To repeat steps in this workflow, use For each item instead.

Error Handler

Catches failures from earlier steps so the workflow can recover — for example notify someone, record the error, or undo an earlier change — instead of just stopping.

Sub-workflow

Runs another workflow in your workspace as a step, so shared logic can live in one place.

Output

Delivers the result of the workflow. Publish Output sends it to a webhook, an HTTP endpoint, email or Slack. Send Email emails it. Generate File produces a file from it. A workflow can have several outputs.

Using data from earlier steps

Any text box that accepts {{…}} can read data from the run. The same rules apply in Dry Run and live runs.

• Only steps connected before the reading step that have finished in this run can be read. A step on another branch, a later or skipped step, or a missing field reads as empty, and the canvas warns you about references it can check.
• Paths use dots and [n] for list positions, for example {{steps.read_rows.rows[0].Email}}.
• References read step outputs only (never credentials) and work after a Human Review or Wait pause. Very large outputs (over 256 KB for one step) read as empty.