Skip to main content

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)
Action outputs are available as template variables: {{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
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
Delay nodes are non-blocking to the engine — the execution is scheduled to resume at the specified time, freeing resources for other workflows.

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.
Any user with the automation:execute permission can approve or reject. The workflow resumes immediately on the first response.
Output Handles:
  • 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:
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:
ForEach loops have a maximum nesting depth of 2. You cannot nest more than 2 ForEach nodes inside each other. The maximum items per loop is 100.

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.
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.
Configuration:

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
Circular references are detected at publish time. You cannot create a subworkflow chain where Workflow A calls B which calls A (directly or indirectly).
Create a “Notification Workflow” that sends alerts to Slack, creates a Jira ticket, and updates the status page. Then invoke it as a subworkflow from any incident response workflow, passing the incident data via input mapping.

Quick Reference