The n8n Lead Stack: One Lead, Five Workflows, One Shared Ledger

One seeded, synthetic, labelled lead travels through five already published workflows from this series, on one fresh, throwaway n8n instance: harvest, speed-to-lead, drafts, inbox router, and a silence watchdog. Episode 10 is not a new workflow — it is an install script that wires five earlier episodes together on one shared ledger, and proves the chain actually connects with a real, controlled run.

install.sh imports all five inactive over the n8n API, wires one shared schema, one shared caps Data Table, and one shared error workflow, then a manual pass runs each brick by hand, in order, for a real execution id. Three of the five runs finish clean; two error on an environment gap, shown on screen rather than hidden. Then, on purpose, the install script runs a second time — and it refuses, on a name collision, on screen.

If iframes are blocked where you are reading this, the video is at the Episode 10 video.

What does the install script actually do?

Five separate, already published workflows go in: a lead harvester, a speed-to-lead responder, a draft personaliser, an inbox router, and a silence watchdog. The install script imports all five inactive, wires one shared schema plus each brick's own tables, creates a shared caps Data Table, and wires a shared error workflow onto all five. It reads back every workflow's active status to prove none of them turned themselves on. Two of the five bricks work outbound — the harvester and the draft personaliser — and three react to what comes in: speed to lead, the inbox router, and the watchdog.

What did the demo run actually show?

The install completed in five to six seconds across the runs measured for this build, with all five workflows read back inactive. One seeded lead's row was run by hand through each brick in order, producing a real execution id on all five: three finished clean, and two errored on an environment gap in the demo box itself — one on a missing model credential, one on an http versus https mismatch — both shown on screen rather than hidden.

Buyer evidence for a bundled stack like this is a hypothesis, not a confirmed demand — stated here plainly rather than dressed up as proof. What is confirmed is narrower and verifiable: five separately published workflows can be chained on one shared ledger, installed together, and torn down cleanly.

The cap sheet

Gotchas worth knowing before you fork this

The watchdog's role in this demo is explicitly not the breaker for the install — it lists all five bricks as manual-run lanes and reminds when one has not been run, it does not detect the manual chain running in real time. And the install script's refusal on a second run is a tested behavior, not an assumption: a second run against an already-populated instance exits with an error and zero changes, workflow and table counts identical before and after.

A rollback drops more than the workflow ids it created — it also drops the shared Postgres tables the install script created, so a torn-down demo instance leaves nothing behind. Nothing in this install or in any of the five bricks activates or sends anything without a person clicking; the standing posture across the whole series is drafts and labels only, never an automatic send.

How do I install it and where are the swap points?

The free workflow JSON for all five bricks is MIT-licensed at github.com/waseemnasir2k26/n8n-workflows/tree/main/workflows/10-lead-stack. Point the install script at a fresh, throwaway n8n instance only — never a production box — export your own base URL, API key, and Postgres credentials, then run install.sh followed by the manual pass script.

Swap points built into the stack on purpose:

1. Every imported brick ships inactive — nothing in this stack turns itself on; a person enables each one only after reviewing it on their own instance.
2. The shared error workflow wired to all five bricks, so one failing brick's errors land in one place rather than five separate logs.
3. A rollback flag on the install script that reverses exactly what it created — workflows, Data Tables, and the shared Postgres tables.

Frequently asked questions

Is this a live, autonomous system?

No. Every brick in this demo is triggered by hand, one at a time, on a throwaway instance built for the recording. The install script never sets a workflow active on its own.

What happens if you run the install script twice?

The second run refuses on a name collision and makes zero changes, shown on screen in the video — an install that could silently double itself is not something we would put on a client's box either.

Why did two of the five bricks error during the run?

Both errors were environment gaps on the demo box itself, not logic bugs in the workflows: a missing model credential on one brick, and an http versus https mismatch on the watchdog's own check. Both are shown on screen rather than edited out.

Does the watchdog detect this manual chain running?

No. Every brick is registered as a manual-run lane, which the watchdog lists and reminds about — it does not detect or flag the manual chain itself, consistent with how a manual-run lane behaves everywhere else in the series.

The rest of the series

One workflow per video, the JSON given away under an MIT license each time, built by Waseem Nasir at SkynetLabs.

• Episode 05, n8n clinic WhatsApp booking agent: a code guard hands off medical and price questions before the model.
• Episode 06, n8n Meta ads circuit breaker: our own breaker missed our own overspend, and this one closed the gap.
• Episode 09, n8n lead draft personaliser: a personalised draft per lead, and still no send node.

Want any of these five bricks installed and tuned on your own instance? Book a discovery call with SkynetLabs.

WhatsApp +92 300 1001957 · Waseem Nasir, SkynetLabs

Hire SkynetLabs, our Top Rated agency on Fiverr: https://www.fiverr.com/agencies/skynetjoellc