02 / DEMONSTRATION · FICTIONAL DATA · LOCAL TESTS
Lead checks
before the CRM.
I built a small demonstration that turns inconsistent form records into prepared CRM fields or visible exceptions. Every input remains accounted for.
- Builder
- Valdeir Lima
- Tools
- n8n workflow JSON, JavaScript, Node.js
- Runtime boundary
- Local transformation tests; no n8n server run
The problem
Form submissions may contain missing fields, duplicate emails and conflicting company information. Passing everything straight through can hide uncertainty inside a CRM.
This fictional demo explores the preparation step: normalise records, apply explicit checks and preserve the records that need review. It does not connect to or write into a CRM.
MANUAL DEMO / SIX N8N NODES
- 01Load the fixtureManual trigger loads eight labelled fictional records
- 02Check the batchNormalise fields, validate and group exact emails
- 03Route each recordAn explicit branch separates prepared and held rows
- 04Inspect the outputTwo prepared payloads; six held with original values
FIXTURE RESULT / FICTIONAL DEMO DATA
8 inputs.
2 prepared. 6 held.
These are the locally tested fixture results, not client metrics. “Prepared” means a generic payload passed the demo’s rules; no CRM sync occurred.
| Record | Result | Reason |
|---|---|---|
| demo-01 | Prepared | Required email and company fields pass the demo rules. |
| demo-02 | Held | Case and whitespace duplicate of demo-01. |
| demo-03 | Prepared | Required email and company fields pass the demo rules. |
| demo-04 | Held | Company name is missing. |
| demo-05 | Held | Email is missing. |
| demo-06 | Held | Same email appears with conflicting companies. |
| demo-07 | Held | The other side of that conflict is retained for review. |
| demo-08 | Held | Email format is invalid. |
Three decisions
in the implementation.
- Use a deterministic batch identity rule. Exact normalised email groups records. The smallest fixture ID is the canonical valid record, so reversing input order leaves the decision unchanged. Identical names with different emails are not merged.
- Hold both sides of a conflict. Conflicting names or companies under one email hold the entire group. The original values remain visible for review.
- Keep preparation separate from a write. Output is a generic contact payload with an explicit “CRM not connected” state. Deduplication applies within this batch only.
How I checked it
A fresh local run on 23 September 2026 passed ten checks. It executed the unchanged source of all four Code nodes with Node.js and n8n-shaped inputs. The harness checked the branch condition and emulated its equality rule; it did not run n8n’s task runner.
Checks covered expected counts and hold reasons, reversed input order, unlabelled data, conflicting names, identical names with different emails, malformed websites and retention of original records. Clearing one required company field changed the result to one prepared and seven held, with every input still accounted for.
The earlier 13 September validation record reports a strict n8n structure check: six nodes, five valid connections and zero errors. It also records six advisory error-handling and fixture warnings. Unexpected code errors stop the manual demo; no retry or recovery mechanism is demonstrated.
REPRODUCIBLE LOCAL EVIDENCE
Inspect the actual files.
The package contains only fictional records and needs no credentials or services. Download the workflow JSON and the verification script into the same writable folder, inspect the source, then run the command below with Node.js. The recorded run used Node.js v25.6.1.
node verify-lead-demo.cjsThis writes a new result JSON beside the script. The harness verifies the reviewed workflow’s hash before executing its Code nodes. It is a fixture-specific check, not a general sandbox for arbitrary workflows.
Before a real
CRM integration.
A real implementation needs agreed field mapping and identity rules, a CRM lookup, duplicate protection across runs, access controls, write receipts, failure review and a small end-to-end acceptance test.
The sample uses reserved .example addresses. It does not establish mailbox deliverability, employment, lead quality or suitability for outreach. No time saving, commercial result or production CRM write is measured.