Inspect workflow failures and recovery

Starting conditions and inputs

Identify the failed workflow run ID, its first failed step, and the source record ID.

Command sequence

open "$entry_url" && snapshot -i

click "$workflow_run" && snapshot -i

get text body

open "$cause_record_url" && snapshot -i

get text body

# Outside browser: The operator corrects the cause and resumes through a supported recovery path. Do not repeat completed sends or payments.

open "$workflow_run_url" && snapshot -i

get text body

Check the result

Successful effects are not duplicated and recovery correlates to the original event.

Resuming after interruption

Check the original request ID and outcome first. Do not resubmit while its result remains unknown.

Even when a workflow is active, an individual run can fail if a customer record is missing a phone number or a channel account loses permission. Re-running the entire workflow blindly can repeat messages or updates that already succeeded in earlier steps.

This guide explains how to inspect Workflow runs and Step runs, separate completed actions from the failed step, and recover safely.

Run status to inspect: failed

Key check before recovery: Whether any succeeded step before the failure already sent a message, placed a call, or processed a payment

Find the run

Open Workflow runs in the left menu. Locate the run by workflow name, status (queued, running, succeeded, failed), and start time, then click the row.

An active badge on the workflow list only means the trigger is enabled. Always check Workflow runs to verify whether individual executions succeeded.

Inspect the failed step

In the workflow run detail pane, inspect the linked Step runs (step_runs) in position order.

1. Check steps completed before the failure: Identify every step marked succeeded before the first failed step. Never repeat a message delivery or payment step that already succeeded.
2. Distinguish skipped from failed: A skipped step means its When (when) branch condition evaluated to false. Open the prior workflows.decide step run and check its output values to see why that branch was not taken.
3. Classify the error cause: Read the failed step's input and error fields to identify the root cause.
   • Missing source data: Empty phone number, missing required custom field, or canceled reservation.
   • Permission denial: The workflow owner's role lacks permission for the step's feature.
   • External provider error: Unapproved template, withdrawn consent, or expired integration credentials.

Choose a safe retry scope

Fix the root cause on the source record ($cause_record_url) or role settings before retrying. Do not assume every screen has a replay button or re-trigger the entire event blindly.

1. Failure before any external effect: A list or decision step can fail before any write or send step runs. Fix the missing data or rule, then let the next schedule tick or supported trigger run it.
2. Failure after a completed send or write: An earlier step can send a message before a later step fails. Complete only the remaining work manually or through a targeted action so the customer does not receive duplicate messages.
3. Repeated failures: Pause the workflow in the Info tab (paused) if an external outage or invalid filter causes repeated failures. Repair the configuration before reactivating it.

Check recovery results

After fixing the cause and completing recovery, verify three records.

1. Source record state: Confirm that the customer, reservation, or purchase record reflects the intended final status.
2. Single delivery or payment: Check Deliveries or Calls to confirm that only one message or call was sent for the event.
3. Audit trail: Keep both the original failed run ID and the recovery run ID for troubleshooting.

If the result differs from what you expected

The workflow run is succeeded, but a step did not run

Check whether the step run status is skipped. Steps with a When (when) condition are skipped without error when the condition is not met. Compare the step's condition chips with the prior decision output.

The same record fails again on the next schedule

Check whether a recurring heartbeat or cron query still selects the unupdated record, or whether a duplicate customer row exists with the same name.

The send step succeeded, but the customer did not receive the message

A succeeded step run confirms that the delivery request was submitted. Check actual handset delivery, consent exclusions, and provider status in message delivery verification.