Flow Designer Error Handling: Try/Catch, Fault Handlers, and Retry Logic

The Try step

The Try step wraps a section of your flow. If any step inside the Try throws an error, execution jumps to the Catch section instead of stopping the flow entirely.

Structure:

Try
  → Step: Call External API
  → Step: Update Record with API response
Catch (Error)
  → Step: Log error to table
  → Step: Send email to admin
  → Step: Update Record with "API call failed" status

What triggers a Catch?

REST calls that return HTTP 4xx or 5xx status codes (depending on configuration)
Script steps that throw exceptions
Look Up steps that return no records and are configured to throw on no result
Action steps that fail (spoke errors)

Error output variables

Inside the Catch block, error data pills are available: error.message, error.stackTrace, error.fault_message. Use these to log meaningful diagnostic information.

Retry logic

For transient failures (network blips, rate limits), add retry logic in the Catch block:

Catch (Error)
  → Condition: Retry count < 3
    → True: Wait 30 seconds → Run Subflow (same operation)
    → False: Log permanent failure → Notify admin

The Flow error log

Every time a flow fails, an error record is created. View at Flow Designer > Flow Error Records. Each error shows the execution context, the step that failed, and the full stack trace. This is your first stop when investigating a failing flow.

Fault handler on the flow itself

You can add a global fault handler at the flow level (not inside a Try step). This catches any unhandled error from anywhere in the flow. Use it as a safety net to ensure critical flows always notify someone on failure.

Testing error paths

Explicitly test your error handling by triggering failure conditions in your test environment. Pass an invalid record sys_id, point at a downed endpoint, or throw an explicit error in a Script step to verify your Catch blocks work as expected.