Catch Block Node
Handle exceptions thrown within the preceding Try Block. Full exception details are injected as memory variables for logging, alerting, and recovery logic.
Exception Variables
When the Catch Block executes, the following memory variables are automatically populated and accessible throughout the catch scope:
__exception can be overridden using the optional error_variable_prefix configuration property. This is useful when using nested try blocks to avoid variable name collisions between the inner and outer catch scopes.
Key Capabilities
- Receives full exception details — type, message, and stack trace — as memory variables immediately accessible to all nodes in the catch scope.
- Supports any node type in the catch scope — Slack notifications, database writes, HTTP requests, Set Variable, Log nodes, and more.
- Optional custom variable prefix (
error_variable_prefix) prevents name collisions in nested try/catch scenarios. - After the catch scope completes, execution proceeds to the Finally Block (if present) or to the nodes following the try/catch/finally trio — the workflow continues rather than terminating.
- Can re-throw exceptions using a dedicated Re-Throw node if you want the exception to propagate to an outer try/catch scope.
- Workflow variables set before the exception occurred are still accessible in the catch scope — allowing you to reference the data that was being processed when the failure happened.
Business Benefits
Without a Catch Block, any unhandled exception would terminate the workflow instance, leaving business data in an inconsistent state and requiring manual intervention to diagnose and restart the process. With the Catch Block, failures become structured events — they are logged, reported, and handled in a predictable, designed way.
For workflows that interact with multiple external systems, the Catch Block is the primary mechanism for ensuring service-level commitments. When an integration fails at 2 AM, the Catch Block automatically logs the error, creates a support ticket in Jira, sends an alert to the on-call team, and records the failure in the audit trail — all before human eyes are even on the problem.
The exception type and message variables allow intelligent branching within the catch scope. An HttpRequestException with status 429 (Too Many Requests) should trigger a retry with exponential backoff, while a UnauthorizedException should trigger credential refresh and a notification to the admin team. The Switch node can route on $mem.__exception_type__ to implement this differentiated handling.
Use Cases
Log Error to Database
Use a Database Insert node in the catch scope to record the error in a workflow_errors table. Capture the workflow ID, node ID, exception type, message, timestamp, and the data that was being processed. This creates a searchable error history for support and debugging teams.
Send Alert Notification on Failure
A Slack notification node in the catch scope sends an immediate alert to the #workflow-errors channel: "Error in [Workflow Name]: {{ $mem.__exception_type__ }} — {{ $mem.__exception_message__ }}. Record: {{ $var.record_id }}." The on-call engineer receives the alert within seconds of the failure.
Retry with Fallback Data
The catch scope sets fallback variable values and then redirects execution to a retry path. A counter variable tracks retry attempts. Combined with a Loop node and an If Condition on the retry count, this implements a controlled retry strategy with a maximum attempt limit before escalating to a human operator.
Create Error Ticket in Jira
An HTTP Request node in the catch scope calls the Jira REST API to create a bug ticket with the exception details pre-populated: title from __exception_type__, description from __exception_message__ and __exception_stacktrace__, and priority based on the workflow's business context. The ticket ID is stored for inclusion in the audit log.
Return User-Friendly Error Message
In a customer-facing API workflow, the catch scope constructs a sanitised error response — translating technical exception details into a user-friendly message — and returns it via the workflow's response output node. The customer sees "We couldn't process your request at this time. Please try again later." rather than an internal stack trace.
In This Guide
Configuration
The optional error_variable_prefix property and variable naming conventions for nested catch blocks.
Input & Output
Output port, exception variable schema, access patterns, and catch scope execution mechanics.
Examples
Error logging, Slack alerts, conditional retry, Jira ticket creation, and graceful API error responses.