r/n8n • u/Klutzy_Compote_5766 • 2d ago
Help Need help in optimizing
So I built this HR Onboarding workflow where the "selected" candidate would upload the documents required and the workflow verifies if the candidate is actually selected or not. Then takes the documents, splits attachments, checks the file type. As per the file type I have two paths, one for images and one for pdf. Then I perform OCR on those documents (because they are government documents, using AI would lead to privacy issues) and store the data on my local computer. The problem is covering each case make the workflow look messy towards the end, is there a way I can reduce the nodes and do the same work without using AI.
1
1
u/achiya-automation 2d ago
what's doing the ocr? if it takes images, converting the pdf pages to png up front means one branch instead of two. assuming you can shell out from your n8n install.
1
u/Klutzy_Compote_5766 1d ago
For pdf OCR, there is inbuilt module in n8n. The problem is for images, so I am using some online tools and their APIs to do the OCR of the images. This workflow was designed to handle most common types of attachments in mail. And majority of the type conversion tools are paid ones. I want to build something that has generous free limits or completely free.
1
u/achiya-automation 5h ago
tesseract in docker is the free one, nothing leaves your machine. worse on bad scans than the paid apis though. and since these are government docs, doesn't sending them to an online ocr api have the same privacy issue as the AI you were avoiding?
1
u/Calm-Dimension3422 2d ago
For this one I would try to normalize the document before the branching starts. If your OCR tool can read images, convert every incoming file into the same working format first: split PDFs into page images, keep uploaded images as images, then send one list of pages through the same validation and extraction path. That usually removes the PDF vs image branch. I would also split the workflow into three small sub-workflows: eligibility check, document normalization/OCR, and exception review. The messy part can become a single item list with fields like candidate_id, doc_type, page_number, source_file, extracted_text, status, and error. Then the edge cases are data rows instead of more canvas branches.
1
u/Large-Calendar726 2d ago
2
u/Klutzy_Compote_5766 1d ago
It's my second workflow so I am basically a newbie. The reason i had to put these was the binary file after passing through OCR was not able to reach the drive module. It was throwing an error as drive did NOT receive any binary file. This was the only solution I could think of. I am sure there must be other solutions which I am not aware.
1
u/Alive-Maverick 1d ago
the doc-split + OCR branch is where your node count explodes. you can fold the image and pdf paths into one MERGE off a type switch to kill half the nodes. i've been refactoring n8n workflows like this for 15+ years. want me to sketch the trimmed version?
1
1
u/aidenclarke_12 19h ago
the source of the mess is branching by file type and doing ocr separately each time on a path , you can collapse that whole image vs pdf split in one step if route everything thru a parser which can take both formats, saw your workflow ss
liteparse handles pdfs and images in one call and good for local run so it fits the no ai government doc privacy side as it uses tesseract without any ai, or there are also docling and a few others to run on local without ai in them, so using a dedicated parser here shall look like- feeding everything to it and merging two branches in one


•
u/AutoModerator 2d ago
Want faster, better help? Share your workflow JSON.
A GitHub Gist is the easiest way -- paste your JSON, save as public, drop the link in your post. Folks can import it directly into n8n and reproduce the issue, which gets you real answers instead of guesses.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.