↵
Handling Error Scenarios
Error handling is the safety net of a workflow. It does not run in the normal flow and activates only when something unexpected happens. There are three kinds of unexpected events a workflow may encounter:
-
Invalid Input: The customer typed something that an input node could not parse, and all retry attempts are exhausted.
-
Error: An API call or action node failed (for example, the transfer system was unreachable, or an email connector failed).
-
Timeout: An API operation took too long to complete.
Error handling is a pattern, not a separate node type. Each relevant node has dedicated output handles for these events. You connect those handles to whatever node you want to handle the failure; typically a Statement node that apologizes and either retries, branches, or leads into a Chat Transfer.
|
Handle |
Appears on |
When it fires |
|
On Invalid Input |
All input nodes |
Customer's response is invalid after all retry attempts. |
|
On Error |
API nodes, all Action nodes |
A call or action fails at runtime. |
|
On Timeout |
API nodes only |
The API operation exceeds the timeout limit. |
Best practices:
-
Always connect error handles. An unwired error handle means the workflow has no graceful path for that failure, and the customer may be left without feedback.
-
For API nodes, connect both On Error and On Timeout to meaningful recovery paths.
-
For action nodes (Chat Transfer, Send to AI Agent, Send Email, Trigger Call), connect On Error to a Statement that informs the customer and offers an alternative.