- The affected automation, run time, and safe source-record identifier
- Access to the run log and current automation definition
- The expected trigger, branch, action, and final state
- A duplicate-effect check before replaying any step
Contain before you explain
If new runs may harm customers or data, an Owner or Admin should pause the workflow from Automations. Pausing stops new live eligibility; inspect existing waiting work separately in Runs.
Automation incident path
- 01ScopeConfirm scope
Identify the workspace, record, channel, time, and affected users.
- 02ObserveCheck visible state
Read the current status instead of repeating the action.
- 03TraceReview history
Use delivery events, audit history, or run logs to find the last good step.
- 04RecoverTry safe recovery
Retry only when duplication and customer impact are understood.
- 05EscalateEscalate with redacted evidence
Share expected versus actual results without secrets or excess customer data.
Find the right failure
- Open the workflow and select Runs.
- Set the smallest time range and filter Failed or Partial.
- Narrow by trigger, step, owner, failure reason, or safe record identifier.
- Expand the run matching the event time.
- Record the published version and trigger context.
- Read the ordered trace to find the first unexpected step.
- Inspect the visible action outcome and any pending resume tied to the run.
- Compare other runs in the same failure group.
| Signature | Meaning | Safe response |
|---|---|---|
| No run exists | Trigger did not fire, scope did not match, or safety/journey eligibility prevented enrollment | Check source event, trigger config, suppression, frequency cap, quiet hours, and re-entry |
| Skipped with safety reason | A guardrail blocked work | Confirm the guardrail is intended; do not remove it just to force a test |
| Failed before any effect | Configuration, data, permission, or provider failed early | Fix cause, simulate retry, then recover one run |
| Partial | Earlier steps completed; later step failed | Inspect every receipt before retry |
| Receipt uncertain | External effect cannot be proven | Do not retry automatically; verify provider/source outcome |
| Resume failed | A wait was scheduled and its continuation failed | Fix cause, then reschedule/cancel that waiting item or recover the run |
Check the source by step type
For messages, verify recipient, consent/purpose, connected sender/inbox, template, and delivery health. For CRM actions, verify the record still exists in this workspace and referenced field, stage, list, tag, or owner is active. For webhooks, verify receiver health and that it can safely ignore a repeated delivery without exposing the key. For waits, verify run time, event/timeout path, and pending-item status.
Recover one run
Use the retry action to run a simulation first. If it passes and every completed side effect has a reusable receipt, confirm Retry original version. Watch the new run. For one waiting item, use Cancel waiting work or Choose a new resume time. Do not roll back the whole workflow for one bad record.
Recover a configuration incident
Pause, open Version history, and compare the current published version with the last known-good snapshot. Make live publishes the selected snapshot as a new version and retains the draft. Test it before turning the workflow on.
Escalation packet
Include workspace slug, workflow name/ID, run ID, published version, approximate time/timezone, trigger type, first unexpected step, run and receipt states, retry simulation result, and redacted error. Exclude message bodies unless necessary and authorized, webhook keys, provider tokens, passwords, and unrelated CRM data.
- Affected records and runs contained
- Correct run and published version identified
- First unexpected step found
- Visible action outcome checked
- Waiting continuation reviewed
- Smallest safe recovery verified