Try Block Node

What it does: The Try Block node marks the beginning of a protected execution region. Nodes placed after the Try Block (inside its scope) execute normally when no errors occur. If any node inside the scope throws an unhandled exception, execution immediately jumps to the paired Catch Block node — the workflow does not fail, and the exception details are made available as memory variables for logging and error handling.

The Try / Catch / Finally Pattern

BizFirstAI's error handling follows the same try/catch/finally paradigm used in programming languages like C#, Java, and Python. Three specialised nodes work together to provide structured exception management within workflow graphs:

Try Block

Nodes placed here execute normally. If any node throws an exception, execution immediately transfers to the Catch Block. If no exception occurs, execution continues normally (and skips the Catch Block, proceeding to Finally if present).

Catch Block

Executes only if an exception was thrown in the Try Block. Exception details (__exception_type__, __exception_message__, __exception_stacktrace__) are available here. Use this scope for error logging, notifications, and recovery logic.

Finally Block (optional)

Executes always — whether the Try Block succeeded or an exception was caught. Use this scope for cleanup, resource release, and audit logging. Runs after both the success path and the catch path.

Pairing requirement: A Try Block node must always be paired with a Catch Block node. A workflow with a Try Block but no Catch Block will fail validation at design time. The Finally Block is optional but recommended for any workflow that acquires resources or needs guaranteed cleanup.

Key Capabilities

Intercepts any unhandled exception thrown by nodes within the guarded scope — including HTTP errors, database errors, expression evaluation errors, and integration timeouts.
Prevents a single node failure from terminating the entire workflow — the process continues with structured error handling instead of an uncontrolled crash.
Pushes a new exception context frame onto the execution stack — nested try/catch blocks are supported for fine-grained error isolation.
Opens a new variable scope — variables set inside the try block are accessible throughout the try/catch/finally trio.
Zero configuration — the Try Block node has no properties. Simply place it in the workflow and connect it before the nodes you want to protect.
Works transparently with all other node types — any BizFirstAI node can be placed inside a try block scope.
Enables graceful degradation patterns: workflows can attempt an operation, catch any failure, and continue with a fallback path rather than requiring a restart.

Business Benefits

Production business workflows must be resilient. External APIs become unavailable. Database connections time out. Third-party services return unexpected responses. Without structured error handling, a single node failure would mark the entire workflow instance as failed, requiring manual intervention to diagnose, fix, and restart — or worse, leaving the business process in an incomplete state with no notification.

The Try Block node enables workflows to anticipate and plan for failures. By wrapping risky operations in a try/catch scope, the workflow designer declares exactly what should happen when things go wrong: log the error, send an alert, retry with fallback data, or return a user-friendly error message. The workflow completes in a controlled manner every time, regardless of external conditions.

This is particularly valuable for workflows that integrate with multiple external systems — where the probability of encountering at least one integration failure during a workflow's lifetime approaches certainty. Try/Catch/Finally transforms error handling from an afterthought into a first-class part of the workflow design.

Use Cases

Wrap External API Calls

An HTTP Request node calling a payment gateway, ERP API, or third-party data service can fail due to network errors, rate limits, or service outages. Wrapping the API call in a Try Block ensures that failures are caught and handled gracefully — the Catch Block can retry after a delay, use cached data, or notify the team — instead of crashing the workflow.

Protect Optional Data Enrichment

When a workflow attempts to enrich a record with data from an external enrichment service (e.g., company data lookup, credit score check), this enrichment is often optional — the workflow should proceed even if enrichment fails. A Try Block wraps the enrichment step; the Catch Block sets default values, and execution continues on the main path.

Safe Retry with Fallback

When processing a batch of records, some individual record operations may fail (e.g., invalid data format). Wrapping each record's processing nodes in a Try Block allows per-record error handling. The Catch Block logs the failed record's ID and continues. The workflow processes all records, collecting errors for a final summary report rather than stopping at the first failure.

Graceful Service Degradation

A workflow that relies on a primary service (e.g., a real-time pricing API) can use a Try Block around the primary call. If it fails, the Catch Block activates the secondary path (cached prices or a default pricing table). The customer-facing workflow completes successfully, and the operations team is alerted about the primary service degradation.

The Try / Catch / Finally Pattern

Key Capabilities

Business Benefits

Use Cases

Wrap External API Calls

Protect Optional Data Enrichment

Safe Retry with Fallback

Graceful Service Degradation

In This Guide

Configuration

Input & Output

Examples