u/easybits_ai

👋 Hey n8n for Beginners Community,

A few days ago someone here asked how to get started with n8n, so I wrote up how I'd approach it from zero (that's the comment in the screenshot). I didn't think much of it, but a bunch of people messaged me asking for more, and it hit me how many of you are trying to find your way into automation right now.

So I'm putting together a short starter guide, the exact path I'd follow if I opened n8n for the first time today.

What's inside

• The four stages to move through, from learning the interface to building anything
• How much to lean on an LLM at each stage (hint: none at the start)
• A simple starter stack worth learning
• The core nodes to get comfortable with first
• A few beginner traps to avoid

How to get it

I set up a quick form in n8n (of course) just to keep track of who's interested, so I can send the guide over. If you want it, drop your details here: https://bisdev.dev.easybits.tech/form/starter-guide

Since I'm still putting it together: what would you hope to get out of a guide like this, beyond the points above? If there's something specific you want covered, mention it in the comments and I'll see if I can work it in.

Best,
Felix

👋 Hey n8n community,

I pulled the image-description part out of a bigger product-content workflow and turned it into a small standalone template, since a few people wanted just that piece. It's now up on the n8n library.

What it does:

• Upload one or more product photos through an n8n form.
• Each image is described on its own (looped, so nothing gets bundled into one call).
• The easybits Extractor returns a structured description per image, which works as product copy and doubles as image alt text.
• You get a styled results page with a thumbnail and a copy button per image, plus a clean fallback when an image can't be read.

Template: https://n8n.io/workflows/16901-generate-product-image-descriptions-from-form-uploads-with-easybits-extractor/

The thing I keep wondering: most shops and sites still write image descriptions and alt text by hand. How are you handling it right now, manual, a vision model, or something automated? And if you were taking this to production, what would you add first, bulk upload, direct publish to your shop, multi-language?

Best,
Felix

👋 Hey n8n community,

A few weeks back I helped one of our users whose data table extraction kept bleeding cells between rows: 95% of the data came out right, but the last 5% landed in the wrong rows, so he could never fully trust it. The way I fix pipelines like that is I never eyeball the output, I build a testing workflow that scores every extraction against a known-good reference so I can benchmark it and see if my changes actually helped.

I shared a first version of that tester, and a bunch of you asked for a v2 that lets you upload your own reference through the same form instead of hardcoding it. So that is what this is.

I also recorded a short video where I run a full test end to end, if you'd rather watch it in action.

How it works:

You upload two things on one form: the document you want to test, and a reference to check it against. The reference can be a CSV (exported straight from Excel) or a PDF/image of the same table. The workflow extracts your document, compares every cell against the reference, and shows a pass/fail card with the accuracy, the mismatches, and how long the extraction took. Each run is logged to a Google Sheet so you can compare engines and track accuracy over time.

The clever bit is trust. A CSV is trusted as-is because a human made it. A PDF reference gets extracted first and shown back to you to confirm before it is used as ground truth, so you are never grading one guess against another.

A few takeaways even if you skip the video:

1. Don't eyeball table extraction. Scoring every cell against a reference tells you exactly which rows slipped, instead of scanning 20 rows by hand.
2. Trust your reference before you trust the test. If your ground truth comes from an extraction too, verify it first, or a "100%" means nothing.
3. When rows slip, refine the descriptions. The easybits Extractor lets you write a description per data field, and that context is usually what fixes it. Tightening a field's description often covers new layouts too, without touching the workflow.
4. Your reference CSV headers have to match your pipeline field names. That one mismatch silently fails every row, so I added a small column map in the workflow to line them up.

Grab the tester here: https://github.com/felix-sattler-easybits/n8n-workflows/blob/e203ef38bc69db58e08e282b18bc287d69d7d85b/easybits-data-table-extraction-testing-tool/easybits_data_table_extraction_testing_workflow.json

It sits in my repo with 20+ other n8n templates I have built with this community: https://github.com/felix-sattler-easybits/n8n-workflows

How do you currently check whether an extraction is actually correct, by hand or with something automated?

Best,
Felix

👋 Hey n8n Community,

I've built a lot of finance workflows over the last few months for friends who run small businesses, and going back through my library I realised I'd never shared the most basic one people keep asking for: a simple batch invoice extractor. So I cleaned one up and pushed it to the n8n template library: Extract batch invoice data from form uploads with easybits and Google Sheets.

The idea is simple. You upload one or many invoices (JPG, PNG, or PDF) through a single form, and it extracts the data from all of them in one go, instead of dragging every invoice in one by one. Each invoice lands as a row in a Google Sheet, and when the batch finishes, the form shows a summary marking every file with a ✅ or ❌ so you instantly see which ones need a second look.

How it's set up:

• An n8n Form takes one or more invoice files.
• The files get split into one item per file, keeping the original filename.
• It loops over the invoices one at a time, sending each to the easybits Extractor, which returns the fields (invoice number, date, vendor, total, and so on) as a structured data object.
• The filename gets reattached, and a check runs over the critical fields.
• One row per invoice is appended to Google Sheets, with a pass/fail status.
• A batch summary is shown as the form's completion message.

A few things from the build that might save you time on your own flows:

• The extractor bundles everything you hand it into one request. Pass it all the files at once and you get one merged result back, not one per invoice. Looping one file at a time is what gives you a clean result per invoice. This one cost me a debugging session.
• Treat "missing" as a signal, not an error. The extractor returns null when a field isn't on the document. Instead of fighting that, I lean into it: a small check flags any invoice missing a critical field, which is what powers the ✅/❌ summary. Worth catching the sneaky empties too (the string "null", empty strings, whitespace), so nothing slips through looking present when it isn't.
• The fields are yours to change. The mapped fields are just a starting point, so you can add whatever you need to pull from your own invoices, like a VAT ID, PO number, or IBAN. The extractor also has auto-mapping, so you can upload one example invoice, let it detect the fields, and tweak from there.

I also recorded a short video showing how it runs end to end, which I'll post alongside this.

For more free workflows, feel free to check my GitHub as well: https://github.com/felix-sattler-easybits/n8n-workflows. A star helps other builders find it, so I'd be really thankful for that support.

How do you all handle the invoices that fail extraction? Curious whether people flag them for manual review like this or route them elsewhere.

Have a good start to the week.

Best,
Felix

👋 Hey n8n Community,

I recently extended my purchase order extractor I'd built so it can also push orders straight into an ERP (my friend's company is moving onto SAP). Getting from "data in a Google Sheet" to "file an ERP will actually accept" taught me a few things that weren't obvious going in. Sharing the five that mattered most.

1. No ERP swallows a raw JSON or PDF. Every real inbound path (SAP IDoc/OData, Oracle's interfaces, or EDI) expects the same shape: a header plus a lines array. "Directly integrable" really just means your output matches that field set, and EDI 850 is the most universal way in.

2. A valid-looking EDI file can still get rejected. My 850 passed every structural check but carried unit words like "piece" and "roll" straight from the PDF. X12 wants coded units (EA, RL) from its 355 list, so I had to map them, otherwise a strict trading partner bounces the line.

3. Fix messy data at the source, not in code. The POs came with dates in both day-first and month-first formats. Instead of guessing in a Code node, I had the extractor output ISO dates. It has the whole page for context to disambiguate, which a regex never does.

4. Deduplicate on business identity, not the file. I key on the PO number against the Google Sheet I already write to, not the filename or file bytes (a re-scan changes those). Adding each new PO number to an in-memory set as I go also catches the same PO uploaded twice in one batch.

5. Fork one clean object instead of branching a monolith. I build the canonical header + lines object once, then split it: one path flattens to the sheet, the other feeds an optional EDI sub-workflow behind a form toggle. One gotcha worth knowing, in a loop, a skipped duplicate still has to return to the loop node, or the whole thing stalls.

Both workflows (main PO extractor + EDI sub-workflow) and a setup guide are here if you want to pull them apart: https://github.com/felix-sattler-easybits/n8n-workflows/tree/f4dec1bef3561aa9e803bb21b96ebff1ab0dde04/easybits-purchase-order-extractor-v2

They live alongside 20+ other n8n workflows in my repo – a star helps other builders find them: https://github.com/felix-sattler-easybits/n8n-workflows

I went with EDI 850 here, but I'm curious what else people are using. Has anyone worked with other formats like cXML, IDoc, or a REST-based import instead? Would love to hear what's held up well for you and what you'd avoid.

Best,
Felix

👋 Hey n8n Community,

A while back I built a purchase order extractor for a friend who was drowning in PO PDFs. It let him batch-upload the documents through a form and pull all the data into a Google Sheet through the easybits extractor. That alone saved him a lot of manual re-typing.

Last week he told me his company is moving onto SAP, and he asked whether the workflow could also spit out EDI files so he can push the orders straight into the ERP instead of keying them in by hand. So I built that in, and while I was at it I made the whole thing a good bit more robust.

How it's set up:

• Batch PDF upload: the form takes one or many PO PDFs at once, and a toggle lets you decide per submission whether you also want EDI files out.
• Extraction: each PO runs through the easybits extractor one at a time and lands in a Google Sheet, one row per line item, with the source document name on every row so you can always trace a row back to its PDF.
• EDI 850 generation (optional): when the toggle is on, each PO is also turned into a valid X12 850 EDI file and saved to a Drive folder, ready to upload into SAP. A separate sub-workflow handles the generation, so the main flow stays clean.
• Duplicate check: after extraction it checks the PO number against what's already in the sheet. If that PO was processed before, it skips it, so you never get double entries.
• Flag summary: the completion screen tells you if any field was missing or looked off in an extraction, and lists any duplicates it skipped along with the PO number.

Short video attached showing a batch run of three POs with EDI generation switched on, then a re-upload of one of them so you can see the duplicate check catch it and report which document and PO number it was.

Both workflows (the main one plus the EDI sub-workflow) and a setup guide are here: https://github.com/felix-sattler-easybits/n8n-workflows/tree/f4dec1bef3561aa9e803bb21b96ebff1ab0dde04/easybits-purchase-order-extractor-v2

You'll also find it alongside 20+ other n8n workflows in my repo. If it's useful to you, a ⭐ really helps other builders discover it too: https://github.com/felix-sattler-easybits/n8n-workflows

Curious how the rest of you are handling the PO-to-ERP step. Are you going through EDI, hitting a direct API, or still uploading into the ERP by hand?

Best,
Felix

👋 Hey n8n Community,

After I built my friend his duplicate invoice checker, he mentioned another problem, his colleague in finance spends about an hour every week manually sorting invoices into Google Drive folders so their tax lawyer gets everything organized. I wanted to see if the easybits Extractor could handle document classification (not just data extraction), so I built a workflow around it. It worked surprisingly well, so I cleaned it up and published it to the n8n template library: Classify invoices and route them to Google Drive with easybits & Slack. I also made a short video showing the classification in action so you can see the full flow before importing anything.

What it does: Upload an invoice (PDF, PNG, or JPEG) through the form trigger, easybits classifies the document and returns a category + confidence score, high confidence routes the file to the matching Google Drive folder, low confidence or no match lands in a "Needs Review" folder with a Slack alert containing the file name, classification result, score, and a direct Drive link.

How it's set up:

Form trigger accepts the upload. easybits Extractor returns two fields: document_class (one of medical_invoice, restaurant_invoice, hotel_invoice, trades_invoice, telecom_invoice, or null) and confidence_score (0.0-1.0). A Merge node recombines the result with the original binary. IF node splits on confidence > 0.5, and a Switch node routes to the correct Google Drive folder. Anything below threshold or unmatched goes to the review path.

Why deterministic and not agentic?

You could solve this with an AI agent that has access to Google Drive and decides where to put files. But agents burn significantly more tokens per run, and for a fixed set of categories a Switch node does the same job for a fraction of the cost. More importantly, agents hallucinate on routing. I've literally seen an agent create a new Drive folder that was never supposed to exist because it didn't know where to put a document – instead of simply flagging it for review. The deterministic approach guarantees that files either land in one of your predefined folders or get flagged. Nothing else.

Quick takeaways:

• Be specific in your classification prompt. Don't just list categories, describe what signals to look for: issuer type, line items, tax patterns, keywords. The more detail, the better the results.
• Treat null as a confident decision. A grocery receipt that clearly isn't any of the five categories should score 1.0, not 0.0. Had this wrong at first and the review queue filled up with obvious non-matches.
• Keep the binary alive. The API returns JSON, but the original PDF disappears from the data flow. A Merge node (Combine by Position) brings it back so your Google Drive nodes have the file to upload.

If this is useful, I'd appreciate a ⭐ on GitHub: felix-sattler-easybits/n8n-workflows. There are 20+ free workflows in that repo covering invoice processing, document classification, and recruiting tools.

For everyone who's still dealing with manual document sorting: how are you handling it today? And if you could improve this workflow for a v2, what would you add or change to make it even better?

Best,
Felix

👋 Hey n8n community,

One of our users reached out with a problem I think a lot of people hit: he was extracting a data table from a multi-page PDF, and the cells kept bleeding into each other. About 95% of the data came out right, but 5% got mixed up with the wrong rows, so he could never fully trust the result.

This week we shipped something to fix exactly that: an extraction engine dropdown you can set per pipeline. In the video I run the same messy multi-page table through both engines, with a small n8n workflow that checks every extracted cell against a reference so you can actually see what slipped.

What the two engines are:

The General engine runs on Gemini and covers about 90% of everyday extraction (image description, classification, normal documents). The Specialized engine runs on Mistral and is OCR-optimized for document-heavy work like dense or multi-page tables.

What the test showed:

The General engine slipped on a couple of rows and came back with pass = false. Switching the pipeline to Specialized took the same document to 100%, every cell correct. The bonus I did not expect: Specialized also ran faster on the multi-page PDF.

A couple of takeaways even if you skip the video:

1. For dense or multi-page tables, reach for the Specialized extraction engine. For most other jobs, General is the right default.
2. Do not eyeball table extraction. A tiny workflow that cross-checks each cell against a known-good reference tells you exactly which rows are wrong, instead of you scanning 20 rows by hand.
3. If rows still bleed after switching engines, it is almost always the response structure. Model the table as one records field set as an array of objects with each column nested inside, not one separate list per column.

Want to try the new engine on your own tables? The easybits Extractor is a verified community node with 50 free monthly API requests included. On n8n Cloud, just search 'easybits Extractor' in the node panel, no install needed. Self-hosted, install '@easybits/n8n-nodes-extractor' from Settings, Community Nodes.

I put a full step-by-step guide (PDF) for setting up your extractor for data tables here: https://github.com/felix-sattler-easybits/n8n-workflows/tree/ee1ed5fe0a3e898843422a619922cedb7cf618c4/easybits-data-table-extraction (the validation workflow from the video is in that same folder too, so you can import it and try it on your own tables)

What is the most stubborn multi-page document you have tried to pull a table out of?

Best,
Felix

👋 Hey NoCodeSaaS community,

A user recently asked whether the extractor I'm using can handle full data tables, not just single fields like an invoice total. So I took a nasty 22-row tax table (multi-line addresses, empty cells, a row split across a page break) and got it to 100%, clean across every run. Sharing the setup plus a small workflow that validates the extraction for you.

The thing that mattered most was how you shape the response structure. One list per column breaks, because nothing links position 4 in the name list to position 4 in the email list. The moment one column has an empty cell, everything below it shifts and you get "a value jumped in from another row." The fix: model the table as a single records field, marked as an array of type object, with each column nested inside. One entry per row, values that cannot drift apart.

A few things that saved me:

1. One array of objects, not one array per column. The only array you want is records itself.
2. "NULL" means two things. A literal value in an empty cell, but a real place name in "NULL City." Spell out the difference or the model guesses.
3. Leading-zero IDs must be strings, or the zero silently drops.

I also built a tiny validation workflow that checks every extracted cell against a reference, flags mismatches, and logs how long extraction took, so you can confirm accuracy holds across runs and compare the two engines.

Where to get it: guide and workflow together in one folder: https://github.com/felix-sattler-easybits/n8n-workflows/tree/ee1ed5fe0a3e898843422a619922cedb7cf618c4/easybits-data-table-extraction

Part of my repo with 20+ other n8n templates I have built with this community: https://github.com/felix-sattler-easybits/n8n-workflows – a star helps other builders find it.

What is the messiest table you have run through an extractor?

Best,
Felix

👋 Hey n8n business automation community,

A user recently asked whether the extractor I'm using can handle full data tables, not just single fields like an invoice total. So I took a nasty 22-row tax table (multi-line addresses, empty cells, a row split across a page break) and got it to 100%, clean across every run. Sharing the setup plus a small workflow that validates the extraction for you.

The thing that mattered most was how you shape the response structure. One list per column breaks, because nothing links position 4 in the name list to position 4 in the email list. The moment one column has an empty cell, everything below it shifts and you get "a value jumped in from another row." The fix: model the table as a single records field, marked as an array of type object, with each column nested inside. One entry per row, values that cannot drift apart.

A few things that saved me:

1. One array of objects, not one array per column. The only array you want is records itself.
2. "NULL" means two things. A literal value in an empty cell, but a real place name in "NULL City." Spell out the difference or the model guesses.
3. Leading-zero IDs must be strings, or the zero silently drops.

I also built a tiny validation workflow that checks every extracted cell against a reference, flags mismatches, and logs how long extraction took, so you can confirm accuracy holds across runs and compare the two engines.

Where to get it: guide and workflow together in one folder: https://github.com/felix-sattler-easybits/n8n-workflows/tree/ee1ed5fe0a3e898843422a619922cedb7cf618c4/easybits-data-table-extraction

Part of my repo with 20+ other n8n templates I have built with this community: https://github.com/felix-sattler-easybits/n8n-workflows – a star helps other builders find it.

What is the messiest table you have run through an extractor?

Best,
Felix

👋 Hey AIStartupAutomation community,

A user recently asked whether the extractor I'm using can handle full data tables, not just single fields like an invoice total. So I took a nasty 22-row tax table (multi-line addresses, empty cells, a row split across a page break) and got it to 100%, clean across every run. Sharing the setup plus a small workflow that validates the extraction for you.

The thing that mattered most was how you shape the response structure. One list per column breaks, because nothing links position 4 in the name list to position 4 in the email list. The moment one column has an empty cell, everything below it shifts and you get "a value jumped in from another row." The fix: model the table as a single records field, marked as an array of type object, with each column nested inside. One entry per row, values that cannot drift apart.

A few things that saved me:

1. One array of objects, not one array per column. The only array you want is records itself.
2. "NULL" means two things. A literal value in an empty cell, but a real place name in "NULL City." Spell out the difference or the model guesses.
3. Leading-zero IDs must be strings, or the zero silently drops.

I also built a tiny validation workflow that checks every extracted cell against a reference, flags mismatches, and logs how long extraction took, so you can confirm accuracy holds across runs and compare the two engines.

Where to get it: guide and workflow together in one folder: https://github.com/felix-sattler-easybits/n8n-workflows/tree/ee1ed5fe0a3e898843422a619922cedb7cf618c4/easybits-data-table-extraction

Part of my repo with 20+ other n8n templates I have built with this community: https://github.com/felix-sattler-easybits/n8n-workflows – a star helps other builders find it.

What is the messiest table you have run through an extractor?

Best,
Felix

👋 Hey n8n for beginners community,

A user recently asked whether the extractor I'm using can handle full data tables, not just single fields like an invoice total. So I took a nasty 22-row tax table (multi-line addresses, empty cells, a row split across a page break) and got it to 100%, clean across every run. Sharing the setup plus a small workflow that validates the extraction for you.

The thing that mattered most was how you shape the response structure. One list per column breaks, because nothing links position 4 in the name list to position 4 in the email list. The moment one column has an empty cell, everything below it shifts and you get "a value jumped in from another row." The fix: model the table as a single records field, marked as an array of type object, with each column nested inside. One entry per row, values that cannot drift apart.

A few things that saved me:

1. One array of objects, not one array per column. The only array you want is records itself.
2. "NULL" means two things. A literal value in an empty cell, but a real place name in "NULL City." Spell out the difference or the model guesses.
3. Leading-zero IDs must be strings, or the zero silently drops.

I also built a tiny validation workflow that checks every extracted cell against a reference, flags mismatches, and logs how long extraction took, so you can confirm accuracy holds across runs and compare the two engines.

Where to get it: guide and workflow together in one folder: https://github.com/felix-sattler-easybits/n8n-workflows/tree/ee1ed5fe0a3e898843422a619922cedb7cf618c4/easybits-data-table-extraction

Part of my repo with 20+ other n8n templates I have built with this community: https://github.com/felix-sattler-easybits/n8n-workflows – a star helps other builders find it.

What is the messiest table you have run through an extractor?

Best,
Felix

👋 Hey n8n community,

A user recently asked whether the extractor I'm using can handle full data tables, not just single fields like an invoice total. So I took a nasty 22-row tax table (multi-line addresses, empty cells, a row split across a page break) and got it to 100%, clean across every run. Sharing the setup plus a small workflow that validates the extraction for you.

The thing that mattered most was how you shape the response structure. One list per column breaks, because nothing links position 4 in the name list to position 4 in the email list. The moment one column has an empty cell, everything below it shifts and you get "a value jumped in from another row." The fix: model the table as a single records field, marked as an array of type object, with each column nested inside. One entry per row, values that cannot drift apart.

A few things that saved me:

1. One array of objects, not one array per column. The only array you want is records itself.
2. "NULL" means two things. A literal value in an empty cell, but a real place name in "NULL City." Spell out the difference or the model guesses.
3. Leading-zero IDs must be strings, or the zero silently drops.

I also built a tiny validation workflow that checks every extracted cell against a reference, flags mismatches, and logs how long extraction took, so you can confirm accuracy holds across runs and compare the two engines.

Where to get it: guide and workflow together in one folder: https://github.com/felix-sattler-easybits/n8n-workflows/tree/ee1ed5fe0a3e898843422a619922cedb7cf618c4/easybits-data-table-extraction

Part of my repo with 20+ other n8n templates I have built with this community: https://github.com/felix-sattler-easybits/n8n-workflows – a star helps other builders find it.

What is the messiest table you have run through an extractor?

Best,
Felix

👋 Hey n8n community,

A while back I posted a two-workflow CV tailor I built for a friend job-hunting (that post here). The tailor workflow itself got most of the attention, but a few people messaged me about the first workflow specifically, the one that takes a CV PDF and turns it into a structured Google Sheet. They wanted just that piece, without the tailoring on top.

Turns out a lot of people have a use case for it that has nothing to do with job hunting. Recruiters wanting to parse candidate CVs into a CRM, people building talent pools, folks who just want their own CV as structured data they can reuse across other tools. So I cleaned it up as a standalone workflow and published it on the n8n template library.

How it's set up:

The form accepts a single CV. It goes straight to the easybits Extractor, which pulls 10 structured fields, kept at exactly 10 so it fits the free plan:

• full_name, email, linkedin_url, location, summary
• experiences (array of role + company + dates + bullets + per-role skills)
• education (array of degree + institution + dates + details)
• skills (flat list, includes certifications)
• languages (with proficiency levels)
• links (GitHub, portfolio, etc.)

A Fan-out Code node then reshapes the extractor's response into four separate row structures, one per Google Sheet tab. Four parallel Split Out + Google Sheets Append branches write to their respective tabs (Master CV, Education, Skills, Summary). A Merge node waits for all four before showing the completion screen with a count of what was imported.

The defensive parsing part was the interesting bit, the Extractor sometimes returns arrays as JSON strings or comma-separated strings, not always as actual arrays. The toArray() helper in the Fan-out node handles all three cases so the workflow doesn't break on shape variations.

I also made a short video showing how it looks in process.

Links:

• n8n template library: https://n8n.io/workflows/15528-create-a-master-cv-google-sheet-from-uploaded-cvs-with-easybits/
• GitHub repo (this workflow + 20 others): https://github.com/felix-sattler-easybits/n8n-workflows – if you find it useful, a ⭐ would help other builders discover it

Curious to hear how others are handling CV parsing today, anyone using it for recruiter workflows or candidate CRMs?

Best,
Felix

👋 Hey n8n Community,

A few weeks ago I built a Slack-based CV assistant for a friend's recruiter, who was drowning in CVs of every imaginable format. Since it landed well, I cleaned it up and pushed it to the n8n template library: Summarize candidate CVs in Slack with easybits Extractor.

What it does:

Recruiter drops a CV (PDF, PNG, or JPG) into a dedicated Slack channel → bot downloads it → runs it through the easybits Extractor with 8 fields → posts a clean structured summary as a threaded reply in the same channel. No leaving Slack, no manual reading, no format guessing.

How it's set up:

The trigger listens for new messages in the channel, ignores its own posts and anything without a file, checks the file type (PDF/PNG/JPG), downloads the private file with a bearer token, and sends the binary to the Extractor. The Extractor returns 8 structured fields, all with a "return null if not present" rule so the summary stays clean:

• full_name
• location
• total_years_experience
• top_skills (top 3 as short noun phrases)
• last_three_roles (title, company, start, end)
• education (degree, institution, year)
• salary_expectations (verbatim string, not normalised)
• linkedin_url

I also made a short video showing the workflow in action so you can see the recruiter flow end to end.

Want the Save-to-Sheet buttons too?

The template above also posts an interactive action card with Save to Sheet and Dismiss buttons under each summary. The workflow that handles those button clicks (appending the candidate to a Google Sheet, updating the card to "✅ Saved by user") is a separate n8n workflow, Slack interactivity needs its own webhook endpoint, so you can't have the trigger and the button listener in the same workflow.

That second part is on my GitHub: felix-sattler-easybits/n8n-workflows, together with 20 other workflows ranging from invoice classification and PO extraction through to more recruiting-side ones like this.

If any of these are useful, I'd hugely appreciate a ⭐ on the repo.

What other recruiter-side workflows are people building in n8n? Curious how far others have taken the ATS integration side of things.

Best,
Felix

👋 Hey n8n community,

A while back I posted a pipeline I built for a friend who runs an online shop, turning his delivery documents into finished product content (that post here). He came back with a follow-up: he wanted SEO in the same place.

Not an SEO platform. His words were roughly "I already come here to create content, I want to come here to fix content too." That framing is why this got built the way it did.

Why not just use Search Console? He has it. He opens it once a quarter, squints at a graph, closes it. The data was never the problem. Search Console tells you a page sits at position 8.9 with 0% CTR, and then stops. It won't rank your 3,000 pages by opportunity, won't tell you what's wrong on the page, and won't write you a better meta. So the real workflow was five tools deep before anything got fixed.

How it's set up:

Quick wins across the site. Pulls every page from the Search Console API, scores each one in a Code node, returns a ranked list. Two signals: striking distance (position 5-15 with real impressions, closest to page one) and low CTR (lots of impressions, barely any clicks, so the title and meta aren't earning it). No page fetching, no LLM. It's fast because it's boring.

Analyze a page. Paste a URL. It fetches the live HTML, pulls the title, meta, headings, alt text and schema, grabs that page's GSC queries, scores it, and hands back paste-ready rewrites grouped by section and ordered by severity.

The two chain: each quick-win row expands and runs the full analysis inline, on click. So you only spend an LLM call on a page you actually decided to work on.

Three things worth stealing:

Deterministic JS scores, the LLM only writes. Fixed rules emit the flags and the severity order. Gemini never grades or reorders. If the model finds the problems and ranks them, you get confident nonsense in an order you can't audit.

Verify every rewrite after generation. A second Code node re-checks each one against the hard limits. First real run, Gemini returned a meta it was very happy with. 160 characters. Limit is 155. That would have shipped truncated.

Rolling date ranges on the GSC query. I hardcoded a window that ended before my data started. GSC returns a clean 200 with no rows, so every node stays green and reports "no data available". Nothing errors. Use new Date(Date.now() - 90*24*60*60*1000) and end 3 days back, since GSC runs ~48h behind.

Both workflows are on GitHub: https://github.com/felix-sattler-easybits/n8n-workflows/tree/367accdd405397366fc93ff391f592d3ec72cc41/easybits-ai-seo-support-workflow

I also made a short video showing how the workflow works.

What signals would you score beyond striking distance and CTR? That's the part I'd most like to improve.

Best,
Felix

👋 Hey businessautomation community,

Quick follow up to my Purchase Order extractor post (that one here). It worked great on the two POs I built it against. Then my friend forwarded three more from different suppliers and things got interesting.

This is the part of document processing nobody warns you about. Your pipeline isn't done when it works on your test files. It's done when it survives the next layout you've never seen. And in a real business, new layouts arrive constantly, every supplier, every hotel group, every ERP exports its own thing. One PO has the number in a top-right box labelled "PO Number". The next calls it "Order Number" in a completely different table. One has a Net column, another calls it Cost, another calls it Total. Same information, nothing in the same place, nothing with the same label.

Here's what surprised me though: the extraction itself never broke. Not once across four layouts. That's because the easybits extractor works off context rather than coordinates, so I describe what the field is ("the order number in the header, not the requisition number below it") instead of where it sits. Move it, rename it, restyle it, it still finds it. If I'd built this with positional templates I'd have needed a new template per supplier, which is exactly the maintenance treadmill I was trying to avoid.

What did break was my own code downstream. Every single time. Two examples:

The apostrophe. One supplier writes 1'550.00 for one thousand five hundred fifty. My parser saw the apostrophe, choked, and mangled the number. The extractor read it perfectly, I just couldn't parse what it handed me.

The dot. This one nearly got me. Another PO showed quantities as 5.000 and I was convinced it meant five thousand, so I "fixed" my parser to strip the dot as a thousands separator. Wrong. It was SAP-style formatting and it meant five. The giveaway was the document's own arithmetic: 5 x 105 = 525, which matched the printed line total and the net total at the bottom. Read as thousands, nothing added up. Lesson: when a number looks ambiguous, the document usually tells you the answer somewhere, check the totals before you touch the code.

So my takeaway from the whole exercise: with context-based extraction, layout variation is mostly a solved problem. The fragile part moves downstream to the boring stuff, number formats, separators, currency prefixes. That's where I'd spend the hardening time on your next build.

Sanitised workflow JSON is on GitHub if you want to try the Purchase Order extractor yourself, feel free to grab it here:
https://github.com/felix-sattler-easybits/n8n-workflows/blob/c38749a68fd6ea4ae6ebff41789d35cceaacdef1/easybits-purchase-order-extractor-workflow/easybits_purchase_order_extractor_workflow.json

I've attached shots of the different layouts (anonymized, of course), so you can see how little they have in common. How are you handling layout drift on your document workflows?

Best,
Felix

👋 Hey NoCodeSaaS community,

Quick follow up to my Purchase Order extractor post (that one here). It worked great on the two POs I built it against. Then my friend forwarded three more from different suppliers and things got interesting.

This is the part of document processing nobody warns you about. Your pipeline isn't done when it works on your test files. It's done when it survives the next layout you've never seen. And in a real business, new layouts arrive constantly, every supplier, every hotel group, every ERP exports its own thing. One PO has the number in a top-right box labelled "PO Number". The next calls it "Order Number" in a completely different table. One has a Net column, another calls it Cost, another calls it Total. Same information, nothing in the same place, nothing with the same label.

Here's what surprised me though: the extraction itself never broke. Not once across four layouts. That's because the easybits extractor works off context rather than coordinates, so I describe what the field is ("the order number in the header, not the requisition number below it") instead of where it sits. Move it, rename it, restyle it, it still finds it. If I'd built this with positional templates I'd have needed a new template per supplier, which is exactly the maintenance treadmill I was trying to avoid.

What did break was my own code downstream. Every single time. Two examples:

The apostrophe. One supplier writes 1'550.00 for one thousand five hundred fifty. My parser saw the apostrophe, choked, and mangled the number. The extractor read it perfectly, I just couldn't parse what it handed me.

The dot. This one nearly got me. Another PO showed quantities as 5.000 and I was convinced it meant five thousand, so I "fixed" my parser to strip the dot as a thousands separator. Wrong. It was SAP-style formatting and it meant five. The giveaway was the document's own arithmetic: 5 x 105 = 525, which matched the printed line total and the net total at the bottom. Read as thousands, nothing added up. Lesson: when a number looks ambiguous, the document usually tells you the answer somewhere, check the totals before you touch the code.

So my takeaway from the whole exercise: with context-based extraction, layout variation is mostly a solved problem. The fragile part moves downstream to the boring stuff, number formats, separators, currency prefixes. That's where I'd spend the hardening time on your next build.

Sanitised workflow JSON is on GitHub if you want to try the Purchase Order extractor yourself, feel free to grab it here:
https://github.com/felix-sattler-easybits/n8n-workflows/blob/c38749a68fd6ea4ae6ebff41789d35cceaacdef1/easybits-purchase-order-extractor-workflow/easybits_purchase_order_extractor_workflow.json

I've attached shots of the different layouts (anonymized, of course), so you can see how little they have in common. How are you handling layout drift on your document workflows?

Best,
Felix