Where should automation stop when information is incomplete?

Write stop conditions before the happy path

Define conditions that must prevent continuation: required field missing, identity conflict, amount outside tolerance, duplicate uncertainty, missing permission or unavailable downstream service. Then specify whether each condition fails, waits, creates a task or asks for review.

Explicit stops prevent convenient but false defaults, such as assigning an unknown supplier to a generic vendor simply to make the workflow pass.

Waiting can be a normal business state, not a failure

Some work legitimately waits for evidence, approval or time. Keep a Waiting state with deadline, owner and resume condition. n8n execution history distinguishes Running, Success, Failed and Waiting, illustrating that paused work can remain an observable execution.

Define escalation after timeout, retry limits and when Waiting becomes Failed or Manual Review so work does not remain silently suspended.

References: [1]

High-impact actions need human approval with enough context

Supplier bank changes, payment approval, policy overrides or low-confidence posting should pause before the consequential action and show evidence, proposed action and likely impact. A bare Approve button without context is not useful control.

n8n supports send-and-wait-for-approval patterns in some integrations and points to the Wait node for more complex approval. This illustrates how human decision can be a first-class workflow state rather than an untracked side conversation.

References: [2]

Retry must not duplicate side effects

Before retrying actions that create invoices, orders or notifications, use idempotency or lookup to establish whether the earlier request already succeeded. A caller timeout does not prove the downstream server did nothing.

Separate retryable technical failures from business errors. An invalid supplier or amount mismatch should not be retried every minute; it should enter an exception queue for the underlying data to be fixed.

Retain evidence explaining why the workflow stopped or continued

For each execution retain workflow/version, trigger identity, input reference, decisions, retries, error category and final outcome while avoiding secrets and unnecessary sensitive data. n8n execution history supports review and retry of failed executions, making retention and access controls part of workflow design.

When automation behaves unexpectedly, the team should be able to identify which input chose the branch, which rule version ran and who approved a resume. “Workflow failed” alone is not enough for auditable work.

References: [1]

Apply it to your business

Trustworthy automation is not measured by how little humans touch. It continues when evidence is sufficient, stops when it is not, and explains why every item reached its state.