He sent me the Loom recording at 11pm on a Sunday, which is how I knew this conversation was going to be more complicated than a technical question. The screen recording showed the n8n workflow I had built him four months earlier, the one that handled purchase order processing, supplier follow-ups, and the weekly reconciliation report that used to take most of a Friday afternoon. He was hovering over the Merge node in the middle of the canvas and his cursor was shaking slightly, the way someone’s cursor shakes when they are stressed and trying not to show it. “This bit,” he said in the voiceover. “When two invoices come from the same supplier in the same week, it’s doing something I don’t understand. Sandra would have caught this. Sandra always caught this.”
Sandra had been his operations manager for six years. She had been made redundant three months after I delivered the workflow.
I called him back the next morning instead of sending a Loom response, because I had looked at the Merge node issue and understood what was happening technically, but the technical answer was not the only thing he was asking.
The workflow was doing what I had built it to do. When two invoices arrived from the same supplier within a seven-day window, the Merge node was combining them into a single record before the approval step, which was the behaviour the business owner had specified in our initial scoping call. He had said he wanted duplicate supplier invoices flagged rather than processed separately. What he had not said, because neither of us had thought to ask, was that Sandra’s version of “flagging” involved calling the supplier to verify whether the second invoice was a duplicate or an additional delivery, before updating the record. The workflow flagged them correctly, combined them in the Merge node correctly, sent the combined record to the approval Slack channel correctly, and left out the verification call entirely, because the verification call was institutional knowledge that lived in Sandra’s head and had never made it into any document I was given to work from.
This is the part of automation that does not appear in the case studies. The business owner had given me his process documentation, a Google Doc that was three pages long and had not been updated since 2021, and a series of Loom recordings of himself walking through what Sandra did each week. The documentation described the steps. It did not describe the judgment calls that happened between the steps, because Sandra had been doing this long enough that the judgment calls were automatic and therefore invisible, and the business owner had been watching her work for six years without ever asking why she picked up the phone before approving certain invoices.
I found this out by asking, during that Monday morning call, what Sandra actually did when two invoices came from the same supplier. He went quiet for a moment. Then he described a process that was not in any of the documentation and not in any of the Loom recordings and was not in the workflow I had built.
The fix was not complicated technically. I added an IF node after the Merge node that checked whether the combined invoice value exceeded a threshold, and if it did, instead of routing to Slack for approval it routed to an HTTP Request node that sent a templated email to the supplier asking them to confirm delivery reference numbers. That email step replaced about sixty percent of what Sandra’s phone calls were doing. The other forty percent, the cases where the supplier needed to be reasoned with, or where the invoice had an error that required negotiation, those still happen, and they land in a Slack channel with a label that says “Needs human review” and they sit there until the business owner deals with them himself, which he does not always do promptly because he hired Sandra partly to make sure he did not have to think about this.
The documentation problem I ran into, separate from the process knowledge issue, was with n8n’s Wait node, which I added so the workflow would pause for forty-eight hours before escalating unconfirmed invoices. The docs describe the Wait node’s resume behaviour clearly enough, but they do not mention that if your n8n instance restarts while a workflow execution is in a Wait state, the execution resumes correctly only if you are using a database for persistence rather than the default SQLite setup. I was using SQLite on this client’s self-hosted instance, which meant that when the EC2 instance rebooted for a routine update while three executions were in a Wait state, those executions simply never resumed. No error. No notification. Three invoices disappeared into the queue and stayed there until the supplier chased the business owner directly. The fix was migrating to Postgres, which the n8n documentation recommends for production but does not specify as required for Wait node reliability.
CrewAI, which some people in the automation space are currently suggesting as a way to build agents that can handle the judgment-call layer I described above, is not ready for this use case. I have built with it. The multi-agent coordination works in demos and falls apart when the agents encounter inputs they were not specifically prompted for, which in a real business process is most of the inputs.
The business owner on that Monday call did not explicitly say he felt guilty. What he said was that Sandra had been very good at her job and that he missed having someone who understood the business well enough to catch things before they became problems. Then he asked me to improve the workflow.
The automation did not replace Sandra. It replaced the parts of Sandra’s job that were already documented. The rest of her job is still happening, just less reliably, and the business owner is starting to understand the difference between what was automated and what was lost.
That distinction matters, and the vendors selling automation will not be the ones to explain it to you.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.