Automation failure recovery: decide what the next attempt repeats.

Recovery is a boundary decision

A failed automation leaves two questions: what has already happened in the destination, and what will the next attempt repeat? This note uses only six first-party pages retrieved on 2026-11-01. Vendor-documented means described by the supplier within those pages; it is not independent verification. We have not performed hands-on vendor testing. The proposed drill below supplies acceptance questions, not observed results, a ranking or an endorsement. These sources do not establish platform reliability, product performance or completeness for your integration. The useful decision is whether your team can explain and control a particular recovery path.

Name the operation before authorizing it

Use these working distinctions in the decision record: retry means another attempt; replay means executing work again using previous data; resume means continuing from retained state; full re-run means starting the workflow again across its entire boundary. Product labels alone do not tell you which side effects will recur. Write down the starting point, saved input, configuration and operations that can repeat. Idempotency is an integration design property: repeated requests must have the intended effect at the receiving boundary. It cannot be inferred from a retry button. This note infers no rollback, exactly-once delivery or transactionality. A destination write followed by a lost acknowledgement is a proposed failure scenario, not evidence that a platform caused or prevented it.

Zapier: distinguish a failed step from the entire run

Vendor-documented — “What is replay?” describes failed-step replay that can skip previously successful steps. When enabled, Autoreplay may attempt replay up to five times. Full-run replay creates a new run and replays every step from the trigger. These are different recovery boundaries, not evidence of duplicate safety. For a proposed drill, mark the destination effect of each step before selecting the operation. A skipped successful step says nothing about an effect inside the failed step. Require the operator to identify that uncertainty before authorizing recovery; do not turn the documented replay behavior into an idempotency claim.

Make: inspect the saved incomplete execution

Vendor-documented — “Manage incomplete executions” places retry at the failed module with the saved configuration. Its manual-resolution instructions separately describe running from that module with original input after settings changes. Keep those operations distinct in the drill record. The incomplete-execution UI exposes status and attempt details. Use that visibility to ask which recovery was requested and what remains unresolved. This note establishes no automatic retry policy, rollback or duplicate suppression. Before another attempt, compare the destination with the expected effects; a module boundary is not proof that nothing happened inside the failed operation.

n8n: saved state still allows repeated work

Vendor-documented — “View all executions” describes retries resuming from saved execution state. The failed node processes saved input again, including previously handled items. Retrying an Execute Sub-workflow node may rerun the whole sub-workflow. Each retry is a new execution: this is an explicit repeat-work risk, not idempotency. In a proposed drill, trace each synthetic item through the destination and connect the new execution to the original failure. A preserved result from a completed node does not settle what happened within the failed node. Choose a recovery owner who checks those effects before another attempt.

Three access questions, not one

Separate credential secrecy, internal sharing permission and provider-side scope. Zapier’s sharing page says recipients can use a connection without seeing login credentials, yet access or update data; revoking sharing from the owner of a published Zap can pause it. Make’s connection page says team users can use and manage team connections; effective scopes remain provider-specific, and insufficient scopes can make a scenario fail. n8n’s sharing page gives Can use permission to run and publish without viewing or editing credential details; provider scope remains a separate evaluation question. Hidden secrets do not answer who can cause a write. For your drill, record the human role, shared connection and permitted destination operation separately, without recording secret values.

Recovery visibility has its own lifetime

Make documents deletion of a resolved incomplete execution after 30 days. That is not a general history retention promise. For n8n, recovery depends on retained execution state; retention is configuration-dependent and its applicable duration remains unknown here. This note establishes no general Zapier history retention period either. Distinguish the availability of recovery state from the period for which a buyer needs an audit record. Ask an owner to resolve those requirements for the intended configuration before relying on later investigation. Do not assume that a visible status today will remain available for the business’s required review window.

Proposed recovery drill: define acceptance first

Use synthetic data in an isolated evaluation workflow and a destination you control. We have not performed this drill. Agree on expected effects and stop conditions before deliberately introducing failures. Keep a small ledger keyed by a synthetic event ID, with expected and observed writes recorded separately. The following acceptance criteria are proposals for the buyer; they are not claims that any supplier passes. Do not send customer data or real notifications. A failed criterion should remain unresolved until an owner supplies evidence or changes the integration design.

• Baseline: assign synthetic event REC-001 and an expected destination ledger. Acceptance: every expected write and notification sink has an identifier, an owner and a recorded expected count before running anything.
• Duplicate delivery: submit the same synthetic event twice. Acceptance: the observed business effects match the pre-agreed count; any extra effect is identified and reconciled. Record whether integration logic or destination behavior handled repetition.
• Partial side effect: arrange a controlled failure after a destination write but before acknowledgement. Acceptance: the operator identifies the existing write before authorizing another attempt and reconciles the final state without unexplained effects.
• Replay boundary: compare the available failed-step retry/resume with full re-run using separate synthetic samples; include a sub-workflow if relevant. Acceptance: record which steps and items repeat and account for each destination effect, not just the final status.
• Credential revocation: remove internal sharing access in the isolated workflow, separately from provider-side credential revocation. Acceptance: record which operation stops, who can restore it and the controlled restart procedure; no restoration uses a personal secret copied into the ledger.
• Insufficient scopes: use a deliberately restricted test connection for the required destination operation. Acceptance: the missing permission is identified, the failure is visible and an authorized owner can propose the minimum required scope; access is not broadened silently.
• Audit visibility: capture permitted run identifiers, status, attempt details and the destination ledger before the applicable deletion window. Acceptance: another authorized reviewer can connect original failure and recovery effects; unavailable evidence or an unknown retention window remains an explicit gap.
• Decision: classify every criterion as accepted, unresolved or outside scope, attaching evidence only after the proposed drill is performed. Acceptance: no essential unresolved criterion is marked passed; record the owner, next action and conditions for repeating the drill after changes.

Make the recovery decision reviewable

Keep four columns in the buyer’s decision record: documented boundary with source and retrieval date, proposed scenario, observed evidence if a trial is later performed, and unresolved dependency with an owner. Do not fill the observation column from documentation. An essential effect that cannot be reconciled should block acceptance of that workflow until the team can explain the discrepancy. A less relevant operation may remain outside the agreed scope. This produces a bounded integration decision, not a universal winner. Use the related automation guide to connect these recovery requirements to the broader workflow brief.