Node Types

Every step in a workflow is a node. Different node types serve different purposes — from running actions to looping over collections to waiting for human approval. This page covers each type, when to use it, and what license tier it requires.

Action Nodes

What they do: Run a single operation — either a connector action that calls an external service, or a built-in transform that processes data locally.

When to use them: For any discrete step in your workflow. Sending an email, creating a record, parsing JSON, filtering a list, making an HTTP request — these are all action nodes.

Tier: Available on all tiers (Starter and above).

Action nodes are the most common node type. You configure them in the Properties Panel with the specific fields required by the action. Their outputs are available to subsequent steps via expressions.

When an action node fails, the workflow engine can automatically retry it based on the configured retry policy. If retries are exhausted, the failure propagates to any connected failure edges.

ForEach Nodes

What they do: Loop over a collection and process each item. Each iteration runs as its own child execution, potentially in parallel.

When to use them: When you have a list of items and need to perform the same operation on each one. For example: process each row in a spreadsheet, send a notification to each team member, or update each record in a batch.

Tier: Enterprise and above.

ForEach nodes take a collection expression as input (e.g., the array output from a previous step) and spawn a child execution for each item. Each child execution runs the steps inside the ForEach loop with that item's data available.

When all iterations complete, the ForEach node aggregates the results — reporting how many iterations succeeded, failed, or were cancelled.

Subworkflow Nodes

What they do: Run another workflow as a step within the current workflow.

When to use them: To compose complex automations from simpler building blocks. If you have a workflow that handles "onboard a new customer," you might have it call separate subworkflows for "create account," "provision resources," and "send welcome email."

Tier: Enterprise and above.

Subworkflow nodes allow you to reuse workflows and keep each workflow focused on a single responsibility. The parent workflow waits for the subworkflow to complete before continuing.

Nesting depth is configurable (default: 5 levels deep) and recursion protection prevents infinite loops where a workflow calls itself.

Agent Nodes

What they do: Use an AI model to reason about a problem, decide which tools to use, and execute a multi-step task autonomously.

When to use them: When the next step is not predetermined — the AI agent needs to analyze the situation and decide what to do. For example: "review this support ticket and take the appropriate action" or "analyze this data and create a summary report."

Tier: Enterprise and above.

Agent nodes are different from regular AI steps (see AI-Powered Workflows). A regular AI step runs a single prompt and returns a result. An Agent node enters a reasoning loop: it thinks about the problem, decides which tool to use, executes the tool, observes the result, and repeats until the task is complete.

The tools available to the agent are configured in the workflow definition. These can include any connector action registered in your deployment, as well as platform tools for managing workflows and executions.

Human Gate Nodes

What they do: Pause the workflow and wait for a human to approve or reject before continuing.

When to use them: For any step where you want human oversight before proceeding. For example: approve a large purchase order, review an AI-generated response before sending it, or authorize a data deletion request.

Tier: Enterprise and above.

When a workflow reaches a Human Gate node, the step is suspended and an approval request is created. The designated approvers are notified and can approve or reject the request. Based on their decision, the workflow either continues along the success path or the failure path.

Human Gate nodes support:

• Configurable approval assignees
• Approval messages with context from previous steps
• Timeout-based escalation if no response is received within a configured period

Conditional Branching

In addition to the node types above, all nodes support conditional edges — connections that fire based on the outcome of the step:

• Success edges fire when the step completes successfully (the default)
• Failure edges fire when the step fails after exhausting retries
• Always edges fire regardless of outcome

This lets you build branching logic directly into your workflow graph. For example, you might have a step that checks a condition, with a success edge leading to one path and a failure edge leading to another.

Summary

Next Steps

• Available Connectors — see what actions are available for Action nodes
• Expressions and Data Flow — pass data between nodes
• Error Handling and Retries — configure what happens when nodes fail