Overview
Workflows are built from 10 node types, each serving a distinct purpose. Drag them from the palette onto the canvas and connect them with edges to define your automation logic.Trigger
The entry point of every workflow. Exactly one Trigger node is required per workflow. Trigger Types:
Trigger Conditions let you filter which events activate the workflow. For example, “only trigger on critical incidents from the payment service.”
For a detailed guide on configuring each trigger type, including conditions, webhooks, and cron expressions, see the Triggers guide.
Action
Executes a task on a target system via an agent and connection. This is the most common node type. Configuration:
Output Handles:
- Success (bottom-left) — Execution succeeded (exit code 0 or HTTP 2xx)
- Error (bottom-right) — Execution failed (non-zero exit, timeout, or error)
{{nodes.<nodeId>.output.stdout}}, {{nodes.<nodeId>.output.statusCode}}, etc.
For a complete reference of all 25+ action types and their parameters, see the Actions guide.
Condition
Branches the workflow based on a boolean expression. The workflow follows the True or False edge based on the evaluation result. Configuration:
Available Operators:
Output Handles:
- True (bottom-left) — Condition evaluated to true
- False (bottom-right) — Condition evaluated to false
Example: Route by Severity
Example: Route by Severity
A condition node checks
{{incident.severity}} equals critical:- True path → Restart service + page on-call engineer
- False path → Send Slack notification only
Delay
Pauses the workflow execution for a specified duration before continuing to the next node. Configuration:
Use cases:
- Wait 5 minutes after restarting a service to verify it’s healthy
- Add a cooldown period between retry attempts
- Delay notifications to avoid alert fatigue during incident storms
Approval
Pauses the workflow and waits for a human to approve or reject before continuing. This is essential for high-risk automations where you want a human in the loop.- Single Approver
- Multi-Approver
Any user with the
automation:execute permission can approve or reject. The workflow resumes immediately on the first response.- Approved (bottom-left) — Approval granted
- Rejected (bottom-right) — Approval denied or timed out
Approvers can add a note when approving or rejecting. The note is recorded in the execution log and accessible via
{{nodes.<nodeId>.output.responseNote}}.Error Handler
Catches failures from upstream nodes and executes remediation logic. Connect an Error Handler to any node’s error output to define what happens when things go wrong. Configuration:
Available error context variables:
Example: SSH Failure → Slack Alert
Example: SSH Failure → Slack Alert
An SSH action tries to restart a service. The Error Handler catches the failure and sends a Slack message:
ForEach
Iterates over a collection and executes the configured action for each item. Useful for operations that need to run across multiple targets. Configuration:
Available loop variables:
Parallel & Join
Parallel
Spawns multiple concurrent branches. Connect multiple nodes to the Parallel node’s outputs to create branches that execute simultaneously. Configuration: No configuration required — the branch structure is defined by the edges you draw.A single workflow supports up to 15 parallel branches. Each branch executes independently on separate agents if available.
Join
Waits for parallel branches to complete before continuing.- All Mode
- Any Mode
Waits for all incoming branches to complete. The workflow continues only when every branch has finished (success or failure).Use this when all parallel operations must complete before proceeding — for example, restarting multiple services before running a health check.
Subworkflow
Invokes another published workflow as a step in the current workflow. This enables modular workflow design — build reusable automation blocks and compose them into larger flows. Configuration:
Output Handles:
- Success (bottom-left) — Subworkflow completed successfully
- Error (bottom-right) — Subworkflow failed

