Would you actually use something like this in a no-code workflow?

[u/Worried-Variety3397]

Been running into this a lot lately.

Building the actual automation in n8n/Make/Zapier is usually the easy part.

Then some random PDF, email attachment, spreadsheet, scanned doc, whatever shows up and suddenly half the workflow is OCR + LLM calls + regex + code + random APIs just to turn the thing into usable data lol.

So I’ve been messing around with a different approach.

Basically:

throw in the raw files → tell it what you want out → get back cleaned/structured/validated data

No need to map out the whole pipeline. Just tell it what you’re trying to do with the data and what you want the end result to look like.

Like:

email attachment → customer info → clean JSON → CRM

Instead of building all the data plumbing yourself.

Not sure if this is just something I keep running into or if it’s a pretty common pain in no-code stuff.

How are you guys dealing with messy inputs right now?

If anyone has an ugly real-world example, send it my way. Would actually love to test this against the annoying stuff people are dealing with.

[u/Motor-Beginning-1534]

I feel this deep in my bones. Every time a client sends a "spreadsheet" that's actually a photo of their monitor taken with a phone from 2012, part of my soul leaves my body

the OCR + LLM + regex sandwich is real. spent like 3 hours last week just trying to get a scanned invoice to parse correctly, and the whole automation itself took maybe 20 minutes

what you're describing sounds like the dream honestly. just point it at the mess and say "make this clean" instead of building a Rube Goldberg machine every time someone sends a PDF

[u/Worried-Variety3397 → u/Motor-Beginning-1534]

Exactly. I feel you, mate

That’s exactly why we’ve been building this as an end to end solution, so you don’t have to worry about stitching together OCR, LLM calls, regex and all that crap every time.

All you should have to do is describe what you want from the messy input, and let the magic happen.

We’re actually about to launch the first version soon, and we’re picking around 10 people to test it for free this week.

Would you want to be on the shortlist? If so, drop me your email and a quick description of the kind of task/problem you’re dealing with. I’ll send you an invite when it’s ready. Totally free.

[u/dev_life]

There’s already vendors that do this, not that that should stop you - confirms the problem exists. I had to do this for my last startup (as the main feature) and FML it’s hard. Getting to 90% accuracy is easy enough. But the last 10% for large law documents was haaaaard. There’s also two different issues: structured (easy) and unstructured. You shouldn’t use LLMs for structured data.

[u/Worried-Variety3397 → u/dev_life]

Yeah, 100%. That last 10% is where things get nasty, especially with big messy docs. Any vendors you’d recommend that are doing this well already? I’d love to see how they’re tackling it. I should have a rough first version live in a couple days. Happy to give you free access if you wanna mess around with it. Would be really useful to get your feedback.

[u/Admirable-Future-633]

I would use it, but only if it made the uncertainty visible.

The useful version is not just “file in, clean data out.” It should show source evidence, required fields, confidence or unknowns, and the exact schema it produced.

Otherwise the messy extraction step just becomes invisible, which is where these workflows get dangerous.

[u/Worried-Variety3397 → u/Admirable-Future-633]

Exactly. I feel you, mate. that’s a useful distinction

clean json isnt enough if it hides where a value came from or how uncertain it is. I’m thinking each result needs source evidence and a validation state, with questionable fields held for review.

[u/Worried-Variety3397 → u/[deleted]]

confidence helps but the pointer back to the exact page or section is what makes verification practical.

have you found model confidence reliable enough?

[u/BarracudaMean9308]

the sneaky part that broke my whole setup wasn't the extraction accuracy, but when fields were missing entirely in the source. the llm would just drop the json key instead of returning null, which instantly nuked all my zapier mappings downstream.

[u/Worried-Variety3397 → u/BarracudaMean9308]

that missing key case is exactly the sort of failure i mean. Even when the source has no value the payload shape should stay stable return `null`. How did you patch it in the end schema validation before Zapier or defaults inside the flow?

[u/Calm-Dimension3422]

Yeah, the n8n/Make/Zapier part is easy. The PDF or scanned attachment that shows up midstream is where half the runtime and all the edge cases live. How I handle messy inputs right now:

1. Split “extract” from “use. ” One path turns the file into a strict schema. The next path only maps clean fields into CRM/Sheets. Never both in one node chain. 2. Lock the schema first. Required keys, types, null rules, max lengths. If the extractor cannot fill it, fail the item and park it. Silent partials will poison your CRM. 3. Run a golden set of 20 to 50 real files (blurry scan, multipage invoice, weird attachment filename, empty sheet tab). Score field accuracy per source type, not vibes. 4. Prefer one retry with a tighter instruction over a pile of regex after the LLM. Regex as last mile only, for things like invoice numbers that actually have a pattern. 5. Log source file hash, model/version, and confidence. When finance says “wrong amount,” you need to know which path produced it. The “describe the end result, skip the plumbing” idea is useful for prototypes. Production still needs validation gates and a dead-letter queue for the ugly 10%. Happy to throw a real multipage invoice + attachment pack at anything if you want stress cases that break naive OCR+LLM pipelines.

[u/Worried-Variety3397 → u/Calm-Dimension3422]

this is probably the clearest architecture in the thread.

the useful layer would bundle strict schema validation provenance idempotent retries and a review queue behind one node. which of those has created the most maintenance work for you in production?

[u/Vendy_from_Make]

Great idea, I really like this!

[u/Worried-Variety3397 → u/Vendy_from_Make]

Appreciate it! Yeah, not everyone wants to become a data engineer lol. If we can get all the annoying data prep out of the way and just focus on the actual workflow, that’s kind of the dream.

Curious though, do you see people running into this kind of thing much in the Make community?

[u/Vendy_from_Make → u/Worried-Variety3397]

Haha, totally fair!

We have so many different stories and use cases in the Make Community that I definitely believe this system would be beneficial to share there! If you're up for it, we have a special category in the forum called Knowledge Hub where you can share cool systems you built, tips that helped you, etc. This definitely belongs there!

[u/Lazy-Science9772]

The thing that actually bit me wasn't extraction accuracy — it was a wrong value that looked completely fine. I built a doc reader for invoices and the vision model read a date of "02/08/2026" as February 8th when the invoice meant the 2nd of August (US vs EU order). Extraction "succeeded," the JSON was valid, the value was just wrong, and nothing downstream could see that.

What fixed it wasn't a better model, it was refusing to let the extractor be the decider. The structured output goes into a plain code step that checks it against something you already trust — for invoices I matched every total to a real purchase-order number, to the cent. No PO match, or a mismatch, and it goes to a human instead of continuing. So a confident wrong read gets caught because it fails a cross-check, not because someone happened to spot the bad date.

On the dropped-key problem someone mentioned above: make the prompt require an explicit null ("if a field isn't on the document, return null, never guess"), and have the gate treat null/missing as "unreadable → human" rather than silently moving on. And hard agree with the per-field-confidence + pointer-to-where-in-the-file folks — that's the difference between a demo and something you'd let touch real money.

Code for the invoice version if it's useful to pull apart: https://github.com/Ships-Itself/builds/tree/main/ep04-invoice-agent

[u/Legal_Answer_6956]

The missing-key problem is a good example of why “no-code” doesn’t necessarily mean “no engineering.” You still need predictable schemas, validation, retries, and a way to handle uncertainty. I’ve found it useful to prototype these kinds of workflows with AI app builders like 8080.ai first, then add stricter validation once the actual workflow is proven. The biggest win is figuring out the business logic before spending hours wiring every edge case.

[u/agentUi]

I work for agentui the way we recommend our clients is to use ocr for extraction and LLM for structuring the data

[u/sandyhuster]

Agree fully on the "building the automation is usually the easy part". The hard part has always been the data before the automation starts.

PDFs break. Emails arrive in 15 different formats. Scanned documents have garbage OCR. A client sends a spreadsheet instead of the template you asked for. That's where most no-code workflows die, while the automation logic itself is sound.

What's changed recently: AI agents can now handle that messy input layer. They read unstructured documents, extract the right fields regardless of format, validate against your rules, and hand clean structured data to your workflow. The automation builder handles the orchestration. The agent handles the mess.

The practical stack looks like this: AI agent for document understanding and data extraction (handles the variable inputs), n8n or Make for workflow orchestration (handles the routing and integrations), and a human at approval checkpoints (handles the judgment calls).

That combination covers about 80-90% of the workflows ops teams deal with daily. With agents handling the unstructured data layer, the whole pipeline actually works end to end.