The message came on a Thursday morning, three days after I finished the project. The workflow was running cleanly: Webhook node receiving form submissions, IF node routing based on approval threshold, HTTP Request node writing approved records back to their internal database, Slack node posting summaries to the right channels. No errors in the execution log, task counts exactly where I expected them. The message from the operations manager said: “We’ve made a decision to let our data coordinator go. The workflow handles everything she was doing.”
I read it twice. Then I closed the tab and went to make tea.
I am going to be honest about the reaction I had, because it is relevant to the larger claim in the title of this piece. I did not feel guilty. I felt something more like unease at the gap between what the workflow actually did and what the operations manager thought it did. The data coordinator had been doing three things. She had been entering data from form submissions into their database, which the workflow now did correctly. She had been chasing approvers who missed their deadlines, which the workflow handled with a daily Cron trigger and a Slack message. And she had been handling the exceptions. The submissions that came in with missing fields. The vendors that submitted duplicate invoices. The cases where the database write failed because the record already existed and needed a different endpoint. The workflow did not handle any of those things, because nobody had told me those things existed until I started asking after I read that message.
The IT department is not dead. The IT department’s relationship with automation is changing, and the companies that are figuring that out are the ones where someone technical enough to understand what an automation actually does is involved in the decision about what to automate. The companies getting into trouble are the ones treating workflow automation as a staff reduction tool first and a reliability question second.
I have built automations that genuinely replaced repetitive work that used to take someone hours per week. I have also built automations that took weeks to build, broke twice in the first month, needed a credential rotation after an API key was rotated on the vendor’s side, and required a two-hour debugging session when a response schema changed without notice and the Set node started mapping null to fields that downstream nodes expected to be strings. The honest accounting of what that automation “saved” depends entirely on whether you are counting the ongoing maintenance time or just the hours of manual data entry it replaced.
What n8n exposes, specifically, is the gap between building a workflow and owning one. Building is the interesting part, the part that the demos show, the part that makes the tool look like it eliminates complexity. Owning is the part that starts a week after delivery, when something changes in the upstream system the workflow depends on and the execution log shows a cryptic error like “Cannot read property ‘items’ of undefined” at the HTTP Request node, and whoever is responsible for the automation has to figure out whether the API changed its response structure, whether the credentials need refreshing, or whether it is something in the Code node that was working before because the input data was always in a particular shape and is now not.
The documentation problem I ran into on this particular project was with n8n’s error workflow feature, which is supposed to let you designate a separate workflow to run whenever any other workflow fails. The docs describe how to configure it and what data gets passed to the error workflow. What they do not describe is that the error workflow receives the error data in a specific structure that is different from what you would expect if you have been working with n8n’s standard item format. The error object is nested inside a json property on the first item, and within that there is a workflow object and a execution object and a node object, and the fields you actually need are two levels deeper than the top-level properties suggest. I found this by running a test failure and piping the error workflow output to a Set node configured to show me the full incoming data, which is not in the documentation, it is just the thing you have to do.
On the question of competing tools and where they sit relative to this: Make.com has a better error handling UI for simple workflows. The error handling is more visual, the retry logic is easier to configure, and the scenario history makes it easier to see what happened at each step when something fails. The problem is that when the workflow is complex enough to matter, Make.com’s execution model starts working against you. Operations managers who chose Make.com because it looked approachable are the same people who end up with fifteen-module scenarios that nobody on their team can read, and when the person who built it leaves, the scenario is effectively a black box with a monthly bill attached.
The enterprises I have seen handle automation well have kept one person whose job includes understanding what the automations do and when they are not doing it. That person is not a coordinator. They are not a traditional IT role either. They are something new, someone technical enough to read an execution log and non-technical enough to talk to the operations team about what the business process actually requires. n8n makes that person more capable, not redundant.
The job functions being eliminated are the repetitive manual ones. The job function that should not be eliminated is the one that owns what happens when the automation is wrong.
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.