The workflow has been running for eight months and I genuinely resent it.
Not because it does not work. It works better than most things I have built. I resent it because of what it revealed about how I was working before it existed, and because once you automate the right thing you cannot un-see all the other things that should also be automated, and that list does not get shorter.
Here is what I built. I use Notion as my primary workspace, which I know is a sentence that makes certain people leave the room, but stay with me. I have a Notion database for client projects, each page with properties for status, deadline, deliverable type, and a checkbox called Ready to Process that I tick when a task is at a stage where something should happen next. When that checkbox gets ticked, an n8n workflow fires. It reads the page properties via the Notion API, routes based on deliverable type using a Switch node, and then does different things depending on what it finds. For certain task types it drafts a status update email using an HTTP Request node to the Claude API with the project context injected into the prompt. For others it creates a follow-up task in the client’s project management tool. For invoice-related completions it hits a second workflow that I built separately and now call from this one, which handles the approval routing I described elsewhere.
The Switch node routing was the part that looked obvious in planning and took the longest to actually build correctly. The Notion API returns property values in a structure that is not complicated exactly, but is also not what you expect the first time. A select property does not return a string. It returns an object with a nested name field, so {{$json.properties[“Deliverable Type”].select.name}} is what you actually need, not {{$json.properties[“Deliverable Type”]}}, which returns something that looks like a value when you hover over it in the input panel but evaluates to [object Object] when you try to use it in a Switch node condition. I know this because I spent ninety minutes wondering why all my tasks were routing to the default branch.
The documentation for the Notion node shows the property access pattern correctly in the reference section. What it does not show is what the expression actually evaluates to at runtime versus what it displays in the node UI during test execution. Those two things are not always the same, and the gap between them is where most of my debugging time goes in n8n generally. I have started writing every expression into a Set node first, running it once, reading the actual output value, and then moving it to where it needs to go. It adds a step every time. It saves an hour every third workflow.
The Claude integration was where this setup went from useful to something I think about differently. I am sending project context, the client name, the deliverable description, the current status, and a short instruction set to the API via an HTTP Request node, getting back a drafted update, and piping it into a Gmail node that creates a draft in the relevant label rather than sending automatically. The model is not sending email on my behalf. It is doing the part I find most draining, which is translating project state into the specific register that different clients expect, and leaving me to review and send. That distinction matters. I have seen people build automation that acts without review and then spend twice as long fixing the consequences.
The reason I said I resent this workflow is what happened after I built it. I looked at my Notion workspace with fresh eyes and saw seventeen other databases that had the same pattern, a status property and a point where something needed to happen next and a human doing the mechanical translation between those two states manually. I had been doing that translation for years without noticing it as a category of work. The workflow made it visible by removing it from one place.
I have since rebuilt four of those patterns. Each one took longer than I thought and worked better than I expected. CrewAI kept coming up in conversations as I was building the more complex multi-step ones, the idea of having agents with defined roles handle different parts of the downstream process. I tried it. I do not recommend it for anything client-facing yet. The agent coordination is impressive when it works and completely opaque when it does not, and in production the ratio of impressive to opaque is not good enough to justify the debugging overhead. When a Switch node routes wrong in n8n I can see exactly why in the execution log. When a CrewAI agent makes an unexpected decision I am reading logs that describe what the agent said it was doing, which is not the same as what it was actually doing. Until that visibility problem is solved it stays in my experimental folder.
What I wish someone had told me before I started combining Notion and n8n seriously is that the combination works best when you treat Notion as the system of record and n8n as the event layer, not the other way around. I have seen people try to use n8n workflows to manage state, storing data in workflow variables, passing it between executions, treating the automation layer as the database. That breaks in ways that are slow and hard to diagnose. Notion holds the state. n8n responds to changes in the state. Keep those responsibilities separate and the whole thing stays comprehensible months later when you have forgotten how you built it.
The honest thing I have concluded after eight months is this: the right automation does not feel like automation after a while, it just feels like work that no longer takes time, and the dangerous part is that once you know what that feels like you cannot stop looking for more of it.
I have twelve tabs open right now. Eleven of them are Notion databases I have not automated yet.
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.