The Real Secret to a Workflow That Doesn't Break

The tools are the easy part. n8n, NocoDB, Gemini, Upload Post — you can replace any of them. What's harder to replace, and what causes the most breakage when it goes wrong, is the data structure underneath.

I learned this by breaking things.

How data moves through Zo.E

When WF2 runs, it sends a topic and some brand context to Gemini and asks for a structured JSON response back. Not a paragraph of text. Not a markdown blob. A proper JSON object with named fields.

Those fields look something like this: body_linkedin, body_bluesky, hashtags, image_prompt, suggested_title.

Each one maps directly to a column in the NocoDB Posts table. Gemini fills in the fields. WF2 writes them to NocoDB. Done.

When WF5 runs later — the distribution workflow — it reads from that same NocoDB row. It picks up body_linkedin and sends it to Upload Post for LinkedIn. It picks up body_bluesky and sends it for Bluesky. Each field goes to exactly the right place because the schema was designed for it.

Why this matters if you're customising the Template Pack

If you rename a NocoDB column, WF5 stops finding the data it's looking for. It'll either error or — worse — post nothing and tell you it succeeded.

If you change the output schema in the Gemini prompt — say you rename body_linkedin to linkedin_post because that feels cleaner — WF2 will write to the wrong field, WF5 will pick up an empty value, and the whole pipeline falls over silently.

The field names are not cosmetic. They're the contract between every workflow in the system. Change them in one place and you have to change them everywhere.

The upside: swapping tools is straightforward

This is why the structure is worth getting right upfront. Because once the data layer is solid, the tools on top of it become interchangeable.

If Upload Post disappeared tomorrow and I had to build a direct LinkedIn integration, one node in WF5 changes. The NocoDB schema doesn't change. The Gemini prompt doesn't change. The field body_linkedin is still called body_linkedin, it's still sitting in the same column, WF5 just sends it somewhere different.

The same logic applies if Gemini gets replaced by a different model, or if NocoDB gets swapped for something else. The workflow architecture stays intact. You're updating a node, not rebuilding a system.

Before you customise anything

Look at the NocoDB Posts table schema first. Understand what every column is for and which workflow writes to it or reads from it. Then look at the Gemini prompt in WF2 — specifically the output format it's being asked to produce. Those two things need to match exactly.

If you want to add a field — say, a body_email column for newsletter content — add it to NocoDB first, then update the Gemini prompt to include it in the output, then build the node in whatever distribution workflow needs it. In that order.

The structure first. The tools follow.

Ta,

James
Founder | Nunlimited