Handle a failed Action through an error route

This operational recipe turns a terminal provider failure into explicit Workflow data and sends it to a recovery Step.

Trigger → Provider Action
                   └─ Error → Recovery Action

Use a safe test Workflow

Do not deliberately break a production credential or send a destructive request. Create a test Workflow and use a read-only Custom API Request against a resource that does not exist, or another controlled operation expected to return a terminal validation or not-found response.

1. Create the failing Action

1. Add a provider Custom API Request Action.
2. Use a safe method such as GET.
3. Point it to a clearly nonexistent test resource.
4. Save the Action and keep its normal Success route disconnected or connected only to a harmless test Step.

A terminal 4xx response is useful for this test because ordinary validation and not-found failures are not expected to wait through retries intended for temporary failures.

2. Connect the Error output

1. Add a recovery Step after the failing Action.
2. Set Input from to the failing Action.
3. Select Error instead of Success.
4. Choose a recovery operation, such as sending a message to a dedicated Slack test channel or appending a failure row to Google Sheets.
5. Map the public error code, message, failed Step identity, response status, and attempt using the error-branch field picker.

Success output fields are intentionally unavailable on the error branch. Use only fields exposed by the normalized error envelope.

3. Run and inspect

Activate the Workflow and produce one test event. In Audit, confirm:

• The provider Action is marked Failed.
• Its error is terminal or has completed applicable retries.
• The Error route is selected and the ordinary Success route is not.
• The recovery Action receives the normalized error input and succeeds.
• The overall run status reflects completed routing while retaining the failed Step evidence.

Decide whether recovery means success

A handled error route can allow the Workflow to complete even though the original Action failed. Keep business-success notifications separate from operational recovery so a recovered technical route is not mistaken for a completed business transaction.

Production checklist

• Filter fallback providers by error code instead of treating every failure as an outage.
• Keep recovery Actions idempotent because they can also retry.
• Avoid exposing credentials or raw provider secrets in alert messages.
• Leave an unhandled route for failures that must stop the business process.
• Test permissions and revoked-account behavior with dedicated non-production accounts.

See Workflow error handling, Paths and conditions, and Runs and errors.