Try / Catch

Runs a sub-graph; if any node inside fails, jumps to the catch branch instead of failing the whole workflow.

Why use it

Some failures are recoverable in a workflow context — a third-party API is temporarily down, a record we expected isn't there. Wrapping the dependent steps in a try_catch lets you handle the failure gracefully (log it, notify Slack, send a fallback email) instead of the whole workflow ending with status: failed.

Inputs

Outputs

• try — sub-graph that runs first. If every node in it succeeds, the workflow continues via the then output.
• catch — runs only if any node in the try branch failed. Receives the original input payload plus an error field with code, message, failed_node_id.
• then — what runs after the try block, regardless of which branch was taken (try success OR catch). Receives a merged payload with whichever branch ran.

The execution status is partial (not failed) when the catch branch fires, so monitoring can distinguish "handled error" from "unhandled failure".

Example

"Send a thank-you email. If SMTP fails, log it to Slack but don't block the rest of the workflow":

try_catch:
  try:
    email.send (thank-you template)
  catch:
    slack.post_message ("SMTP failed for order {{trigger.order_id}}: {{catch.error.message}}")
  then:
    crm.update_contact (mark as notified)