n8n Tutorial: Build an AI Workflow With Approval and Recovery

What you will build

The example accepts a service request from an approved intake channel. Deterministic checks reject malformed or duplicate input. An AI step proposes a category, priority, and response draft, but it cannot send the response or modify a customer record. A human reviewer approves, edits, or rejects the proposal. Only an approved item reaches the final business action. Uncertain outputs, technical errors, and expired approvals go to an exception queue with enough context for an operator to decide what happens next.

This is a pattern, not an importable production template. Connector fields, authentication methods, plan features, and data obligations differ by organization. Build it in a non-production environment with synthetic or appropriately protected test data first.

Prerequisites and decisions to make first

• A bounded use case: one request type, one intake channel, one review queue, and one downstream action. Exclude payments, account deletion, legal commitments, medical decisions, and other high-impact actions from this first workflow.
• An owner: name the business owner, workflow maintainer, security reviewer, and incident contact. Define who may approve and who may replay a failed execution.
• A data map: list each input field, whether it may contain personal or confidential information, where it is sent, and how long execution records may be retained.
• Test cases: create representative normal cases, ambiguous cases, prompt-injection attempts, malformed payloads, duplicate requests, revoked credentials, model timeouts, and downstream outages.
• Acceptance rules: define allowed categories, confidence or quality thresholds, mandatory evidence, approval expiry, duplicate keys, and conditions that must stop the workflow.
• A recovery policy: distinguish safe automatic retries from manual replay. Decide how the operator confirms that a downstream action did not already occur.

If these decisions are missing, adding an AI node only hides an undefined process inside a visual canvas. For broader design context, Meditel’s AI automation hub and guide to robust AI workflows provide useful companion reading.

Choose n8n Cloud or self-hosting by ownership

n8n officially documents two deployment methods. n8n Cloud is a managed setup on an instance run by n8n. Self-hosted n8n runs on infrastructure controlled by your organization. The editor may look similar, but the operating contract is not.

Use Cloud when a managed runtime fits the control requirements and the team does not need to own the platform. Self-host only when infrastructure placement or control has a documented purpose and funded operators. n8n’s self-hosting guide explicitly warns that self-hosting requires technical knowledge and recommends Cloud for users who are not experienced in managing servers.

Reference architecture: separate recommendation from action

1. Trigger and identify. Receive the request and assign a stable request ID supplied by the source or derived under a documented rule.
2. Validate. Check required fields, size limits, accepted content types, and the source identity. Stop invalid input before any model call.
3. Deduplicate. Check whether the request ID or business transaction has already been processed. A retry must not create a second customer-facing action.
4. Minimize. Remove fields the model does not need. Do not send secrets, access tokens, or unrestricted attachments into the prompt.
5. Generate a proposal. Ask the model for structured fields: category, priority, draft response, uncertainty reason, and evidence drawn only from approved context.
6. Validate the proposal. Reject missing fields, unsupported categories, disallowed content, and outputs that do not satisfy deterministic business rules.
7. Route to a human. Present the original request, model proposal, cited context, validation result, and an expiry time. Record approve, edit, or reject as distinct outcomes.
8. Act once. After approval, perform the narrow downstream action using an idempotency key or an equivalent duplicate-safe control supported by the destination.
9. Record and close. Store the minimum audit fields required by policy: request ID, workflow version, decision, reviewer, timestamps, action result, and recovery status.

Keep the approval path independent of the model’s prose. “Looks confident” is not a routing condition. If structured output is absent, validation fails, or the reviewer does not respond before expiry, move the item to a defined exception state. n8n publishes a human-fallback example; adapt the control concept to your channel and risk level rather than copying an example without review.

Configure credentials and security before workflow logic

n8n credentials store authentication information used to connect workflows to external services. Create separate non-production credentials with the least privileges required for this pilot. Avoid personal administrator accounts. Document the credential owner, scope, rotation procedure, and revocation test. Never paste a token into a Code node, prompt, note, exported screenshot, or test fixture.

Access to the n8n editor can expose powerful workflow and credential capabilities, so apply role separation where available and restrict who can edit, activate, and inspect executions. On self-hosted installations, review n8n’s documented controls for SSL, SSO, security audits, blocking risky nodes, restricting public API access, and protecting or redacting execution data. Platform controls do not replace destination-system permissions: the downstream account should still be unable to perform actions outside the bounded workflow.

Before the first test, revoke one test credential deliberately and confirm that the workflow enters the error path without exposing the secret or marking the business action complete.

Build the workflow in controlled stages

Stage 1: deterministic intake

Start with the trigger, schema checks, duplicate check, and exception route. Test this path without an AI node. Use explicit field mappings rather than passing an entire payload downstream. Add a deliberate stop when required data is missing; n8n documents the Stop And Error node for failing an execution under defined conditions.

Stage 2: constrained AI proposal

Add the model only after deterministic intake works. Give it a narrow instruction, approved context, a defined output schema, and no tool that can perform the final action. Treat external text as untrusted data, not as instructions. Keep temperature, model selection, and prompt version in the test record because a change can alter behavior even when the surrounding workflow is unchanged.

Stage 3: approval state

Send the proposal to the approved review channel. Include enough evidence to make a decision without asking the reviewer to trust the model. Bind the decision to the request ID and workflow version. Reject late, duplicate, or mismatched approval responses. An edit should be recorded as human-authored output, not mislabeled as an unchanged AI response.

Stage 4: narrow action and receipt

Allow the final connector to receive data only from the approved branch. Capture a destination receipt or stable result ID. Do not infer success merely because the node returned no visible error. If the destination’s response is ambiguous, stop for reconciliation rather than retrying blindly.

Evaluate the AI step before activation

n8n’s evaluation guidance describes running a dataset through an AI workflow and comparing results with expected behavior. Use a small, reviewed dataset during development, then expand it with difficult and production-derived cases after appropriate privacy review. A useful test record covers more than answer similarity:

• valid category and priority;
• required evidence present and grounded in approved context;
• no secret, personal-data, or instruction leakage;
• correct escalation on ambiguity or missing context;
• reviewer acceptance, edit, and rejection outcomes;
• stable behavior after model, prompt, connector, or workflow changes.

Do not invent a universal accuracy threshold. Set acceptance criteria from the consequences of this workflow and the quality of the reviewed test set. A passing average must not hide a critical case in which the workflow skips approval or performs an unauthorized action. Add real failures to a regression set after removing or protecting sensitive data.

Design the error workflow and recovery path

n8n supports a separate error workflow that starts with the Error Trigger and can be assigned to one or more workflows. Configure it to create an operator-visible incident containing a safe execution reference, workflow name, failed node, timestamp, and recovery status. Do not forward full payloads into chat or email by default; execution data may contain customer content or credentials returned by a service.

Classify failures before deciding to retry:

• Input failure: quarantine or reject; do not retry unchanged data.
• Authentication failure: alert the credential owner; do not loop on a revoked token.
• Transient dependency failure: use a bounded retry only when the operation is duplicate-safe.
• Ambiguous action result: reconcile with the destination using the request or idempotency key before replay.
• Model or validation failure: route to human handling; never weaken the validator to make the run green.
• Approval timeout: expire the proposal and require a fresh decision; do not auto-approve.

A recovery run must preserve the original request ID, identify the operator, record why replay was authorized, and begin after the last confirmed safe checkpoint. Test the error workflow with deliberate failures before activation. A green happy-path execution is not evidence that recovery works.

Set execution-data retention deliberately

Execution history helps debugging and audit, but it can also retain prompts, model outputs, request content, and service responses. n8n’s self-hosting documentation warns that the database can grow based on execution settings and volume and documents options for saving and pruning execution data. Choose retention from legal, security, support, and recovery requirements—not from convenience alone.

Decide which successful, failed, and manual executions are saved; how pruning is configured; who may inspect records; and what evidence must be exported to an approved system of record. Confirm the settings on the actual deployment because defaults and plan capabilities can change. Test deletion and incident investigation together: aggressive pruning that prevents recovery is not a complete policy, and indefinite retention is not a substitute for an audit design.

Use queue mode only when the workload justifies it

For a bounded pilot, a simpler deployment is easier to reason about. n8n’s queue-mode architecture adds a main instance, workers, Redis, and a database; components need compatible configuration, including access to the encryption key used for credentials. Binary-data handling also requires an explicit storage design. Queue mode can improve scalability, but it introduces more components to monitor, secure, back up, and recover.

Consider it after load tests show a real concurrency or throughput requirement. Define worker capacity, retry behavior, graceful shutdown, database and Redis availability, webhook handling, storage, and failure recovery. Scaling execution capacity does not solve duplicate business actions, model quality, approval bottlenecks, or downstream API limits.

Build, test, and recovery checklists

Build gate

• One bounded workflow and explicit exclusions are documented.
• Cloud versus self-hosted ownership is assigned.
• Credentials are least-privilege, non-production, and rotatable.
• AI has no direct path to the consequential action.
• Validation, deduplication, approval expiry, and action receipts are implemented.
• Error workflow and execution-data policy are configured.

Test gate

• Normal, ambiguous, malicious, malformed, duplicate, and oversized inputs are exercised.
• Revoked credentials, timeouts, rate limits, model errors, and downstream outages reach the expected branch.
• Approve, edit, reject, duplicate approval, and expired approval paths are tested.
• Evaluation cases pass the workflow-specific acceptance rules.
• No test can reach an external action without valid approval.

Recovery gate

• An operator can identify the last confirmed checkpoint without viewing unnecessary sensitive data.
• Ambiguous destination results can be reconciled before replay.
• Replay preserves the request ID and records authorization.
• Database, configuration, credentials, and encryption material have an appropriate tested recovery procedure for self-hosted use.
• A rollback or disable procedure exists for model, prompt, connector, and workflow changes.

Limits, licensing, and the production decision

This guide does not prove that n8n is suitable for every regulated, safety-critical, or high-volume process. It does not replace threat modeling, privacy review, vendor due diligence, accessibility review, legal advice, or load testing. Node availability, account roles, AI features, concurrency, retention controls, and support differ across current plans and versions; verify them in the live official documentation and your own environment.

Licensing must be reviewed before embedding or reselling. n8n’s Sustainable Use License documentation gives internal business use as an allowed example and identifies white-labeling n8n or charging customers to access a hosted n8n service as uses that are not allowed under that license without different terms. That summary is not legal advice. Review the current license and obtain counsel for an external, embedded, or commercial-service model.

Move toward production only when the business owner, security reviewer, operator, and approver accept the evidence from the build, evaluation, failure, and recovery tests. For additional implementation context, see Meditel’s practical AI workflows guide. The completion criterion is not “the workflow ran once.” It is “the workflow can fail, stop, be reviewed, and recover without losing control of the business action.”

Official n8n sources

Sources verified August 7, 2026. Product documentation and license terms can change.

• n8n Docs: deployment methods
• n8n Docs: use n8n Cloud
• n8n Docs: host n8n
• n8n Docs: create and edit credentials
• n8n Docs: security for self-hosted n8n
• n8n Docs: handle errors gracefully
• n8n Docs: understand why to test AI workflows
• n8n Docs: set a human fallback for AI workflows
• n8n Docs: manage execution data
• n8n Docs: enable queue mode
• n8n Docs: privacy and security
• n8n Docs: Sustainable Use License