Node Types

FlowTrux workflows are built from five node types. Each type has a distinct color in the visual editor and serves a specific role in the execution pipeline.

Trigger (Emerald)

The Trigger node is the entry point of every workflow. Each workflow must have exactly one Trigger node. It defines how the workflow is started and what initial data is available.

Trigger Types

Manual

Run the workflow by clicking the Run button in the editor. You can optionally provide static JSON data that will be available as {{trigger.data}} during execution.

Configuration:

Webhook

Expose an HTTP POST endpoint at /api/webhooks/[workflowId]. External services call this URL to start the workflow. All webhook requests require HMAC-SHA256 signature verification via the X-Webhook-Signature header. See Webhooks API Reference for full details on authentication, request format, and response modes.

Configuration:

Response Modes:

The POST body becomes {{trigger.data}}. URL query parameters are available at {{trigger.data._query}}.

Cron

Run the workflow on a schedule defined by a cron expression.

Configuration:

Form

Trigger the workflow when a public form is submitted. Forms are created in Settings → Forms and assigned to workspaces.

Configuration:

Form data is available as {{trigger.data.fields.<fieldName>}}. File uploads include name, size, contentType, and key.

See Forms for form creation, branding, and embed mode.

---

Agent (Violet)

The Agent node sends a prompt to an AI model and returns the response. It can optionally use tools provided by MCP servers configured for the workspace. See Agent Nodes for detailed usage and AI Providers for supported models.

Configuration:

Output: Accessible via {{steps.nodeId.output.response}}.

Available Models:

The model dropdown in the editor only shows models from providers that have been configured and assigned to the current workspace.

---

Action (Blue)

Action nodes perform operations such as HTTP requests, MCP tool calls, data transformations, and timed delays.

Action Types

HTTP

Send an HTTP request to an external URL. All fields support template variables.

SSRF protection is enforced: requests to private IP addresses, non-HTTP protocols, and DNS-resolved internal addresses are blocked.

Database

Execute SQL queries against external PostgreSQL or MySQL databases.

Output: { rows: [...], rowCount, fields: ["col1", "col2"], truncated: boolean }

Connection strings should be stored as Global Context variables ({{global.dbUrl}}) rather than hardcoded in the node configuration.

MCP

Call a tool on an MCP server that has been configured for the workspace.

Transform

Evaluate a JavaScript expression in a sandboxed environment. Useful for reshaping data between nodes.

The sandbox has a 3-second timeout and no access to process, fetch, or require. Previous node outputs are available within the expression context.

RAG

Search a knowledge base using semantic similarity.

Delay

Pause execution for a specified duration before continuing to the next node.

Maximum delay is 7 days.

Short delay (up to 10 seconds): In-process setTimeout. The worker stays active during the delay.

Long delay (over 10 seconds, up to 7 days): The workflow suspends and the worker slot is freed. A BullMQ delayed job resumes execution after the delay period. This is persistent - it survives server restarts because state is saved in PostgreSQL and the timer lives in Redis.

Short delay output: { delayed: true, durationMs, requested: { duration, unit } }

Long delay output: { delayed: true, longDelay: true, durationMs, resumedAt }

Generate Callback URL

Generates a unique callback URL that external systems can POST to. Used together with Wait for Callback for approval flows and human-in-the-loop patterns.

Output: { callbackUrl, token, expiresAt }

Wait for Callback

Pauses the workflow until an external system POSTs data to the callback URL generated by a previous Generate Callback URL node.

The workflow enters PAUSED state. When the external system POSTs to the callback URL, the workflow resumes. If no callback arrives within the timeout, the execution fails.

Output after resume: { callbackData: { ...data from POST body... }, resumed: true, resumedAt }

Typical flow:

1. Generate Callback URL → creates URL and token
2. Slack MCP / Gmail MCP → sends the callbackUrl to an approver
3. Wait for Callback → pauses the workflow
4. Approver clicks button / POSTs to URL → workflow resumes with callback data
5. If-Else → branches on {{steps.<wait-node>.output.callbackData.action}}

---

Logic (Amber)

Logic nodes control the flow of execution through branching and iteration.

Logic Types

If-Else

Evaluate a condition and route execution to the true or false branch.

Two editing modes:

• Builder mode - visual rule-based editor. Add rules with a variable picker, operator dropdown (equals, not equals, contains, greater than, is empty, etc.), and value input. Rules are connected with AND or OR.
• Code mode - raw JavaScript expression using standard operators: ===, !==, &&, ||, !, >, <, >=, <=.

Both modes generate the same JavaScript expression - the execution engine uses the condition field regardless of mode.

Example (Code mode):

{{steps.action-1.output.count}} > 0 && {{steps.api.output.status}} === 200

Connection hints: Green output = true branch, Red output = false branch.

Switch

Evaluate multiple conditions and route execution to the first matching case.

Loop

Iterate over an array, executing the body nodes for each element.

Inside the loop body, two special variables are available:

• {{item}} -- the current array element
• {{index}} -- the current iteration index (0-based)

Example: Loop over {{steps.agent-1.output.response.messages}} and process each element with {"text": "{{item}}"}.

Loop results are collected in loop.output.results[].

Parallel

Execute multiple branches concurrently. All branches run at the same time and their outputs can be combined with an Aggregator node.

---

Aggregator (Cyan)

Aggregator nodes combine outputs from parallel branches or loop iterations into a single result.

Aggregator Types

Aggregators are typically placed after Parallel or Loop nodes to collect and unify their outputs before passing data to downstream nodes.