> ## Documentation Index
> Fetch the complete documentation index at: https://cobalt-55-abhishek.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Try & Catch node
> Handle errors gracefully by wrapping nodes in a try block with an optional catch branch for error recovery
The Try & Catch node provides error handling within workflows by wrapping nodes in a protected block. When a node inside the try block fails, execution branches to the catch path for error recovery instead of failing the entire workflow. This enables graceful degradation, fallback logic, and controlled error responses.
## When to use
* Wrap API calls that may fail due to external system issues
* Handle record-not-found scenarios without workflow failure
* Implement fallback logic when primary operations fail
* Log errors and continue processing remaining items
* Provide meaningful error responses instead of generic failures
The Try & Catch node is a container node similar to the Loop node. Place the nodes you want to protect inside the container. The catch branch extends from the right side of the container.
## Node structure
The Try & Catch node has three connection points:
| Connection | Location | Purpose |
| ---------------- | --------------------- | ------------------------------------------- |
| **Try Block** | Inside container | Nodes to execute and monitor for errors |
| **Catch Branch** | Right side (red line) | Error handling path when try block fails |
| **Success Path** | Bottom | Normal continuation when try block succeeds |
## Execution behavior
| Scenario | Behavior |
| ------------------------------- | -------------------------------------------------------------------- |
| Try block succeeds | Workflow continues via bottom branch (success path) |
| Try block fails, catch succeeds | Workflow continues via bottom branch after catch completes |
| Try block fails, catch fails | Entire workflow execution fails with error status |
| Multiple nodes in try block | First failure triggers catch branch; remaining try nodes are skipped |
If both the try block and catch branch fail, the workflow execution errors out completely. Ensure your catch branch handles errors reliably.
## Output
The Try & Catch node outputs execution status and error details when applicable.
**When try block succeeds:**
```json theme={null}
{
"status": "Success",
"node_id": "9",
"node_name": "Try & Catch",
"body": {
"try_catch_result": true,
"message": "Try-catch block completed successfully"
}
}
```
**When catch branch executes and succeeds:**
```json theme={null}
{
"status": "Success",
"node_id": "9",
"node_name": "Try & Catch",
"body": {
"try_catch_result": true,
"message": "Catch flow completed successfully",
"failed_node_id": "3",
"error_message": {
"message": "Request failed with status code 404",
"error": [
{
"errorCode": "NOT_FOUND",
"message": "The requested resource does not exist"
}
]
}
}
}
```
**Output Fields:**
| Field | Type | Description |
| ------------------ | ------- | -------------------------------------------------------------------------------------- |
| `try_catch_result` | boolean | `true` if execution completed (try or catch succeeded), `false` during catch execution |
| `message` | string | Status message describing execution outcome |
| `failed_node_id` | string | ID of the node that failed in the try block (only present when catch executes) |
| `error_message` | object | Error details from the failed node including message and error array |
## Adding to your workflow
In the workflow editor, click **Add Node** and select **Try & Catch** from the utility nodes section. The node appears as a container with a dashed border.
Drag nodes inside the Try & Catch container. These nodes execute in sequence and are monitored for errors. Place nodes that might fail (API calls, data lookups) inside.
Connect a node to the right side of the Try & Catch container (red connection line). This branch executes only when a node in the try block fails.
Connect the bottom of the Try & Catch container to the next node in your workflow. This path executes when either the try block succeeds or the catch branch completes successfully.
In your catch branch nodes, use templating to access error information:
```
{{try_catch_node.body.error_message.message}}
{{try_catch_node.body.failed_node_id}}
```
## Settings
The Try & Catch node includes standard node settings available in the Settings tab:
Specify the Node Rule Conditions under which the Try & Catch node should execute. Use AND/OR logic to combine multiple conditions.
`Yes` or `No`. When enabled, the node can complete with a partial success status instead of failing outright.
`Yes` or `No`. When enabled, the node is skipped if it encounters an error, and the workflow continues without executing the try block.
Configure automatic retry behavior for the Try & Catch node itself.
| Setting | Description |
| -------------- | ------------------------------------------------------------ |
| Retry Strategy | `Fixed` (constant delay) or `Exponential` (increasing delay) |
| Delay (ms) | Time between retry attempts in milliseconds |
| Max Attempts | Maximum number of retry attempts |
## Examples
Handle record-not-found errors when fetching Salesforce data by creating a default record.
**Workflow Structure:**
1. **Start Node** - Receives contact ID
2. **Try & Catch Node** - Contains Salesforce lookup
* **Try Block**: Salesforce "Get Contact by ID"
* **Catch Branch**: Custom Code to create default contact object
3. **Continue Processing** - Uses contact data (from try or catch)
**Catch Branch Configuration (Custom Code):**
```javascript theme={null}
function yourFunction(params) {
return {
contact: {
id: params.contact_id,
name: "Unknown Contact",
email: null,
source: "fallback",
error: params.error_message
}
};
}
```
**Use Case:** Workflow continues with default data when contact not found, preventing failure for downstream processing.
Log API errors to a table for monitoring while allowing workflow to continue.
**Workflow Structure:**
1. **Start Node** - Receives vendor data
2. **Try & Catch Node** - Contains NetSuite API call
* **Try Block**: NetSuite "Create Vendor"
* **Catch Branch**: Tables Node to log error + Email Node to notify ops
3. **Response Node** - Returns result
**Catch Branch - Tables Node Configuration:**
| Field | Value |
| -------------- | ---------------------------------------------------------- |
| Action | Add Table Record |
| Table | error\_logs (persistent) |
| vendor\_id | `{{start.body.vendor_id}}` |
| error\_code | `{{try_catch_node.body.error_message.error[0].errorCode}}` |
| error\_message | `{{try_catch_node.body.error_message.message}}` |
| timestamp | `{{instance_meta_data.instance_created_time}}` |
**Use Case:** Errors are logged for analysis while workflow provides graceful response instead of failing.
Attempt payment submission with automatic retry, falling back to queue for manual processing.
**Workflow Structure:**
1. **Start Node** - Receives payment request
2. **Try & Catch Node** (with Retry Strategy enabled)
* **Try Block**: Tipalti "Submit Payment"
* **Catch Branch**: Tables Node to add to manual processing queue
3. **Response Node** - Returns submission status
**Try & Catch Settings:**
| Setting | Value |
| -------------- | ----------- |
| Retry Strategy | Enabled |
| Policy | Exponential |
| Delay | 1000 ms |
| Attempts | 3 |
**Catch Branch - Tables Node Configuration:**
| Field | Value |
| --------------- | ----------------------------------------------- |
| Action | Add Table Record |
| Table | payment\_queue (persistent) |
| payment\_id | `{{start.body.payment_id}}` |
| vendor\_id | `{{start.body.vendor_id}}` |
| amount | `{{start.body.amount}}` |
| failure\_reason | `{{try_catch_node.body.error_message.message}}` |
| status | `pending_manual_review` |
**Use Case:** Payment attempts retry automatically. After all retries fail, payment is queued for manual processing instead of being lost.
Complex error handling with logging, notification, and alternative processing.
**Workflow Structure:**
1. **Start Node** - Receives invoice data
2. **Try & Catch Node**
* **Try Block**: SAP "Create Invoice"
* **Catch Branch**:
* Log Node (record error)
* Email Node (notify finance team)
* Tables Node (queue for retry)
3. **Rule Node** - Check if invoice was created
4. **Response Node** - Return appropriate status
**Catch Branch - Log Node:**
```
SAP Invoice Creation Failed
Invoice ID: {{start.body.invoice_id}}
Error: {{try_catch_node.body.error_message.message}}
Failed Node: {{try_catch_node.body.failed_node_id}}
```
**Catch Branch - Email Node:**
| Field | Value |
| ------- | --------------------------------------------------------------------------------------------------------------------- |
| To | [finance-ops@company.com](mailto:finance-ops@company.com) |
| Subject | `SAP Invoice Creation Failed - {{start.body.invoice_id}}` |
| Body | Invoice creation failed and has been queued for manual review. Error: `{{try_catch_node.body.error_message.message}}` |
**Use Case:** Comprehensive error handling ensures visibility into failures while maintaining workflow completion.
## Accessing error details
When the catch branch executes, error information from the failed node is available via templating:
| Data | Template Syntax |
| ----------------- | ---------------------------------------------------------- |
| Error message | `{{try_catch_node.body.error_message.message}}` |
| Error code | `{{try_catch_node.body.error_message.error[0].errorCode}}` |
| Error description | `{{try_catch_node.body.error_message.error[0].message}}` |
| Failed node ID | `{{try_catch_node.body.failed_node_id}}` |
| Try-catch result | `{{try_catch_node.body.try_catch_result}}` |
Replace `try_catch_node` with your actual node name or use the node number syntax `{{node.9.body.error_message.message}}`.
## Troubleshooting
| Problem | Solution |
| -------------------------- | ------------------------------------------------------------------------------------- |
| Error not caught | Verify the failing node is inside the Try & Catch container, not connected externally |
| Catch branch not connected | Ensure the catch branch is connected to the right side of the container (red line) |
| Skip Node On Error enabled | Set "Skip Node On Error" to `No` in Settings if you want error handling to execute |
| Problem | Solution |
| ----------------------- | ---------------------------------------------------------------------------------------- |
| Catch branch also fails | Add error handling within the catch branch itself, or use a simpler fallback operation |
| Error in catch node | Review catch branch node configuration. Use Log node to debug before complex operations. |
| Missing error details | Ensure you're using correct templating syntax to access error\_message object |
| Problem | Solution |
| ---------------------- | ------------------------------------------------------------------------------------------ |
| error\_message is null | Some failures may not provide detailed error info. Check the failed node's logs directly. |
| Wrong template path | Use `{{try_catch_node.body.error_message.message}}` not `{{try_catch_node.error_message}}` |
| Accessing wrong node | Verify you're referencing the Try & Catch node, not the failed node inside it |
| Problem | Solution |
| -------------------------------- | ---------------------------------------------------------------------------------- |
| Bottom branch not running | Verify connection from bottom of Try & Catch container to next node |
| Catch branch blocks continuation | Ensure catch branch completes successfully. Add error handling in catch if needed. |
| Conditions blocking execution | Check Settings > Conditions if configured |
## Best practices
* **Keep catch branches simple**: Use reliable operations (logging, tables) that are unlikely to fail
* **Always log errors**: Even if you handle them gracefully, log error details for debugging
* **Use meaningful fallbacks**: Provide default values or alternative processing instead of just suppressing errors
* **Don't nest Try & Catch excessively**: One level of error handling is usually sufficient
* **Test both paths**: Verify workflow behavior when try succeeds and when it fails
## Next steps
End workflows with a specific error status.
Record error details for debugging.
Queue failed items for retry.
Process items with individual error handling.