Document Parser

Documents arrive constantly — a signed contract, a purchase order, a supplier's price list, a CV attached to an application. Every one of them is content your workflow cannot see, because a file is not text until something reads it.

This node reads it. Point it at a file, get back the words, and everything downstream — a model, a knowledge base, a CRM field — can work with them.

content_source picks the route: a file uploaded through the product, one referenced by id, a public URL, raw base64, or a path in storage. file_id is the common one — it is how a chat attachment or an uploaded document is addressed.

Eleven formats, and images are not among them. Plain text, markdown, CSV, JSON, PDF, and the Office pairs — Word, Excel, PowerPoint, old and new. A photograph of a document is rejected before anything is attempted. That surprises people, because the node has OCR — but OCR here is for PDFs whose pages are images, not for image files.

Somebody attaches a file to a chat message. The parser reads it, and the workflow checks that there was anything to read before it does anything else.

The trigger exposes file_ids for whatever was attached, and the parser takes the list. Everything after that hangs on one number.

Branch on char_count, not on whether the node succeeded. A PDF that is one big scanned image, a password-protected file, a document that is genuinely blank — all of these parse without error and produce almost nothing. Two hundred characters is a reasonable floor for “this is a real document”; below it, say so rather than passing an empty string to a model that will invent a summary of it.

Some PDFs contain text. Others contain pictures of text — anything scanned, faxed, or exported from a photo. The first kind reads instantly and for nothing. The second needs optical character recognition, and this node will do it for you.

ocr_min_chars_per_page is what decides whether auto fires. Fifty characters a page is a low bar — a page with a header and a page number clears it. If documents that clearly need OCR are not getting it, raise the threshold rather than switching to always.

An unreadable file is a successful run with no text. This is the same failure that has appeared throughout the course, and here it is especially easy to hit, because the reasons are mundane: the PDF is a scan and OCR is off, the file is protected, the format is one of the many not in the list. The node returns, the run is green, and the next node receives an empty string.

In a batch, unsupported files are skipped rather than failing. Hand it five files where two are images and you get three files' worth of text and a successful run. Compare the number of files you sent with what came back if the count matters.

Both limits truncate silently. max_chars and max_pages stop the read at a hundred thousand characters and fifty pages by default. A sixty-page contract is read as far as page fifty, and nothing says the last ten pages exist. If you are parsing long documents, raise them deliberately and check {{alias.page_count}} against what you expected.

Parsed text is not structured data. A table in a PDF comes out as words in reading order, and a two-column layout can interleave. If you need fields rather than prose, the parser gets you the text and a model gets you the fields — this node does not do the second part.