An n8n workflow is ready for production review when its failure path is visible.

01 / SYSTEM CONTRACT

Name what enters, what changes, and what counts as accepted.

Start with the business event, not the first node. The reviewer should be able to trace one input through validation, decisions, side effects, and the final state without opening every node.

• Write the workflow purpose in one sentence and name the business event that starts it.
• Record the systems of record and which system owns each important field.
• Validate required input before any external side effect.
• Define what must be withheld when data is stale, partial, malformed, or unauthorized.
• Separate technical completion from business acceptance.

02 / SAFE EXECUTION

Design duplicate, retry, and terminal behavior before launch.

n8n can repeat work because a trigger redelivers, an operator replays a run, or a dependency times out after accepting a request. A workflow needs one stable business-event identity and a safe answer for each of those paths.

• Derive an idempotency key from the business event, not from the execution attempt.
• State how long duplicate history must remain available and where it is stored.
• Reconcile an ambiguous remote write before issuing the same side effect again.
• Retry only failures classified as temporary, with a finite attempt budget and delay.
• Route invalid input, authorization failure, schema drift, and exhausted retry to explicit terminal states.
• Give manual replay the same duplicate and side-effect controls as automatic retry.
• Test success, duplicate, retryable failure, permanent failure, and ambiguous side effect as separate fixtures.

03 / AI DECISION BOUNDARY

Validate model output before treating it as workflow state.

Free-form model text is not a dependable system contract. When an AI step influences routing, communication, records, access, money, or another consequential outcome, its output needs structural validation and an explicit review rule.

• Require a bounded schema with allowed values, required fields, and length limits.
• Reject malformed or extra output instead of silently guessing what it meant.
• Keep deterministic policy and authorization checks outside the prompt.
• Route uncertainty, missing evidence, policy exceptions, and high-impact actions to a person.
• Give the reviewer the source reference, proposed output, reason, uncertainty, prior action, and available choices.
• Record prompt or policy version, model identifier, validation result, and human decision without copying unnecessary sensitive content.
• Test refusal, malformed output, conflicting evidence, prompt injection, and unavailable-model paths.

Human review is a control only when the reviewer can understand the consequence and has a real option to stop it.

04 / SECRETS AND DATA

Keep credentials out of workflow logic, exports, and evidence.

Production access should be replaceable, revocable, and narrower than the builder account. The workflow export and handoff packet should remain useful without containing the secrets that make live access possible.

• Use managed n8n credentials or an approved secret store; never paste secrets into Code nodes, Set nodes, URLs, examples, or notes.
• Assign separate least-privilege credentials for the approved environment and actions.
• Confirm test and production credentials, webhooks, databases, and endpoints cannot be confused.
• Minimize personal or confidential data at intake and redact it from logs and error notifications.
• Use synthetic or sanitized fixtures for routine tests and handoff evidence.
• Document credential owner, rotation path, revocation path, and what fails when access is removed.
• Review community nodes and external dependencies before they receive data or credentials.

05 / RUN EVIDENCE

Make a failed run findable and actionable.

Operational evidence should let a responder answer what ran, which version ran, what changed, what remains uncertain, and who owns the next action. More log volume is not a substitute for those answers.

• Define success, degraded, review-required, failed, and unavailable states.
• Alert on actionable state transitions, not every repeated symptom.
• Track queue age, exhausted retries, unresolved side effects, and source freshness where relevant.
• Test the alert route and recovery instructions with a controlled failure.
• Set an evidence-retention period that supports investigation without retaining unnecessary data.

06 / RELEASE AND HANDOFF

Release a version that another person can operate and reverse.

The production review should use a frozen workflow version, known configuration inventory, fixture evidence, remaining-risk record, and rollback trigger. Connecting credentials is a release decision, not the final development step.

1. 01
   Freeze the candidate

   Export or version the exact workflow and record its dependencies without secrets.

2. 02
   Run the acceptance set

   Capture expected results for happy path, duplicates, failures, AI exceptions, and recovery.

3. 03
   Review access and configuration

   Confirm environment separation, least privilege, source rights, data handling, and alert ownership.

4. 04
   Decide production connection

   An accountable owner accepts the evidence, remaining risks, release window, and rollback trigger.

5. 05
   Verify and hand off

   Confirm the expected live state, then provide version, setup, monitoring, replay, recovery, and escalation notes.

• The exact candidate version and configuration inventory are recorded.
• Every acceptance fixture has an expected result and captured evidence.
• Known limitations and unsupported cases are explicit.
• Production owner, operator, reviewer, and incident contact are named.
• Rollback or disable steps are safe, tested where practical, and assigned.
• The runbook explains normal operation, replay, recovery, credential rotation, and escalation.
• Final acceptance is recorded by the accountable owner.