Attachments are the part of your automation nobody tested
File attachments break automated workflows without ever turning a run red: size limits, Base64 overhead, signature images that count as attachments, portal links instead of files, and filename collisions that quietly overwrite documents.
Attachments are the part of your automation nobody tested
A finance team we worked with kept every incoming invoice in one archive folder. When we counted, the folder held about 1,100 files, and 180 of them were email signature logos. Small PNGs from supplier footers, filed as if they were invoices, because the workflow had been told to save the first attachment and a signature image is an attachment.
Every one of those 180 logos marks an email where the invoice itself was never saved. Seven months, no failed runs, nothing in the log. What finally exposed it was month-end reconciliation: three suppliers were chasing payment for invoices the accounting system had never seen.
An attachment is not a field
Moving an invoice number between modules costs nothing. A file gets carried, and most platforms encode it as Base64 in transit, which inflates it by about a third. A 28 MB scan travels as roughly 38 MB and stays in memory for the length of the run.
The limits sit in three different places and rarely in the same documentation: how much data the platform holds per execution, what a webhook accepts as a payload, and what the destination system takes on upload. Sending adds a fourth, because most mailboxes stop somewhere around 25 MB per message including encoding. None of this shows up while you build, since you build against whatever sample file was in your downloads folder, and that file was 200 KB.
The failure modes that don't look like failures
Size is the obvious one. A supplier replaces a scanner, 400 KB PDFs turn into 28 MB colour scans, and the upload starts timing out.
The quiet ones do more damage. Most scenarios read attachment number one, so when a supplier sends two delivery notes in a single email, the second one is simply gone. Signature graphics arrive as real attachments carrying a content ID, which is how logos end up in an invoice archive. And increasingly the invoice is not attached at all: larger suppliers put it in a portal and email a download link that expires in 14 days, so the message has zero attachments and still represents work somebody has to do.
Forwarded mail is its own category. Depending on the client, the invoice is no longer attached to the message at all but wrapped inside an embedded original, so the workflow sees one file called message.eml and has nothing useful to do with it.
Filenames finish the job. If every supplier calls their file invoice.pdf and the workflow writes to one folder without adding a prefix of its own, it overwrites itself, and the archive keeps one document where it should keep twelve.
Why the log stays green
None of this produces an error. No attachment is a valid state, a 4 KB PNG is a valid file, an overwritten document is a successful upload.
We catch problems because something turns red. These never turn red, which is why they run for months and why they are usually found by a person comparing two numbers in a spreadsheet for an unrelated reason.
What we do instead
Get the file out of the workflow in the first step. Store it once, in S3 or SharePoint or wherever the documents already live, then pass a path or an ID through the rest of the scenario. Memory limits and Base64 overhead stop being your problem, and a retry no longer drags the binary through five modules again.
Read size and MIME type from the message metadata before downloading anything. Anything above a threshold you chose on purpose goes to a branch that tells a human, rather than dying halfway through an upload. Select files with a positive filter on application/pdf instead of a list of exclusions, and drop attachments that carry a content ID, since those are the embedded signature images.
Set the filename yourself: date, message ID, cleaned original name. Unique, and still traceable back to the email it came from.
Give the no-attachment case its own path. It should look for a download link in the body and create a task when it finds none, instead of marking the email as handled.
Add a count on top of that. Once a day, a small job puts two numbers next to each other: how many messages the workflow marked as processed, and how many documents arrived in the target folder. If they differ, someone gets a message. It is not elegant, and it would have caught the finance team's problem in week one instead of month seven.
Then test the extremes that actually occur. A 30 MB scan. Twelve attachments in one message. A message containing nothing but a signature logo. Two files with the same name. That takes an afternoon.
Rebuilding the flow for the finance team took a day. Getting seven months of missing invoices back out of supplier portals took three people most of a week, and two suppliers had already sent the account to a collections agency.