n8n inquiry-routing tutorial: 12 synthetic cases, review only

Finish a review draft, not just an installation

This exercise checks 12 synthetic inquiries, assigns review labels, and preserves the link to each input. It uses no model and sends no email or CRM update. It is not a customer case.

Recorded evidence, 2026-09-05 UTC: an isolated n8n 2.37.10 / Node v24.20.0 CLI imported, exported and executed the workflow through the JavaScript task runner. All 12 complete items, including pairedItem, matched an independent oracle. The editor root returned HTTP 404 in this npm setup: GUI import and GUI execution were not verified. This is neither production acceptance nor an efficiency or security benchmark.

1. Get the matching files

Download the workflow JSON, 12 inputs, independent expected output, actual output and runtime record. The README lists the source and test files.

Use only these shipped synthetic inputs. Example-domain validation cannot prove that arbitrary text is synthetic or remove personal information. Do not substitute customer inquiries, credentials or internal price lists.

With the repository's examples/inquiry-routing/ directory and an existing Node 22, a developer can run dependency-free policy tests:

node --test examples/inquiry-routing/policy.test.mjs

This does not launch n8n. The stored-evidence check detects file drift; it is not a new runtime execution.

2. Inspect the input and three-node graph

Each item contains { json: { inquiry: dataObject } }. Required inquiry fields are id, email, language, message and quantity. IDs use DEMO- plus three digits; language is exactly en or zh; quantity is an integer from 1 to 100000, never a coerced numeric string. Messages are capped at 2000 raw UTF-16 units. See the README for every field cap and the 50-item batch limit.

Manual Trigger → Synthetic Fixtures (Code) → Review Only - Never Send (Code)

Both Code nodes use JavaScript / Run Once for All Items. There are no HTTP, email, CRM, model, credential, schedule or external-write nodes. A reviewQueue is only a label: it does not assign or notify a person. Every result requires requiresHumanReview: true and sendAllowed: false.

3. Import and execute only in an approved disposable instance

Do not reuse a production database, replace global Node or install n8n into the website. Follow official Docker guidance and licensing for operational deployment. This temporary npm installation warned that non-container operation is deprecated; it is not a production recipe.

The recorded check used CLI import, not an asserted editor click-through. Put one unchanged workflow.json in an otherwise empty import directory and use import:workflow --separate. Export before execution. Require one workflow, unchanged nodes/connections/settings, no credentials, active: false and activeVersionId: null. Only then execute its generated ID with execute --id=… --rawOutput. The CLI reproduction notes specify the isolated environment and acceptance checks.

Ordinary single-file import failed on the absent workflow ID in this version. --separate generated a fresh ID. Do not add a reusable fixed ID: importing an existing ID can overwrite a workflow. Keep fixtures and the oracle out of the import directory.

For a graphical editor, official documentation describes Import from File. In your actual version, inspect warnings, the three nodes and unpublished status before a manual test. That remains an unverified UI path, not part of the successful CLI claim.

4. Check the whole result

Compare every field of all 12 final items with the oracle in order, including pairedItem. A count or green screenshot is insufficient. Pairing metadata may be absent from the editor's JSON view; the CLI notes identify its full execution-data location.

Check the four status counts and review/no-send flags on every item. Stop on errors, missing items or any mismatch. A successful execution does not mean a human approved anything; this workflow has no approval or sending transition.

5. Handle failures without inventing a success

• Missing information: preserve the missing-field reason; a reviewer supplies synthetic test data rather than guessing or silently defaulting.
• Wrong types, extra fields and oversize input: preserve an error item. Do not coerce or truncate. Parsed-data limits are not upload-byte or memory protection.
• Instruction and unsupported-claim signals: hold for policy review. Regexes have false positives and misses; they do not establish injection resistance or factual truth.
• Ordinary drafts: still verify quantity and context. Price, stock, lead time and certification are unverified, not values to fill from imagination.
• Import/version errors: retain the actual failure. Native Node parity and n8n import are separate evidence tiers.

An authorized person can record revise/reject/approve, identity and time in an appropriate private record. The exercise still ends at a draft. Real inputs, approval enforcement, access control and delivery need another design and review—not a change to sendAllowed.

Choose the next task

These are exercise roles, not exclusive capabilities: n8n also documents RAG workflows.

FAQ

Why no model?

A repeatable baseline makes a later model change separately testable instead of mixing several sources of uncertainty.

Do 12 passing cases prove business performance?

No. They are hand-authored synthetic inputs, not a customer population, efficiency benchmark or security certification. No sends, growth, conversions or hours saved were measured.

Did the workflow obtain human approval?

No. requiresHumanReview states an obligation, not a completed review. A queue label does not deliver a task.

Sources and version

n8n export/import, Code node and server CLI. Documentation establishes interfaces; the attached execution record establishes only the version-specific result described here.