A client reached out to me a while back. They'd been using Notion for about eighteen months, knew their workspace well, had it organized exactly how they liked it. They brought me in to connect n8n to their project database, automate some client onboarding tasks, link a few things to their CRM. Standard stuff.
We built it, tested it, everything worked. I handed it off, they were happy, I moved on.
Eleven days later they messaged me. Three of the workflows had stopped writing data correctly. No error messages. No alerts. The n8n execution logs showed green across the board. But the Notion records weren't getting updated the way they should.
It took me about ten minutes to find it. During a team retro they had renamed the "Status" property to "Project Stage" because someone felt it sounded more professional. That is a totally reasonable thing to do, and nobody thought twice about it. Why would they?
But n8n was referencing that property by its exact display name. When the name changed, the automation didn't crash. It just... missed. Kept running, kept triggering, kept showing green. And kept writing data to a field that no longer existed under that name.
This is one of four mistakes I see break Notion automations over and over again. None of them are complicated. All of them are invisible until they're not.
Mistake 1: Renaming Properties After the Automation Is Built
This is the most common one. And it's the most painful because it's so easy to do without realizing.
Here's the technical reason it happens. When n8n writes to a Notion database, it references properties by their display name, not by some internal identifier that stays stable across renames. So if your workflow is configured to write to a field called "Status," and you rename that field to "Project Stage," the workflow doesn't update automatically. It keeps looking for "Status," doesn't find it, and either writes nothing or throws a validation error that gets swallowed somewhere in the flow.
The execution log still shows green. That's the part that makes it hard to catch.
What you'd normally expect from a broken system is some kind of signal. An error. A failed run. Something that tells you to go look. Notion property rename breaks give you nothing. The workflow fires, executes, completes, and logs success. The data just ends up wrong or missing.
Why this keeps happening
From inside Notion, renaming a property feels like a cosmetic change. You're just updating a label. There's no indication that other systems are depending on that name. Notion doesn't warn you. n8n doesn't warn you. There's no connection between the visual rename action and the automation that's three integrations away.
Most clients I work with understand their Notion workspace really well and understand n8n barely at all. They think in terms of what they see in Notion. And what they see in Notion is a property label that can be changed anytime.
The fix
When I hand off an automation now, I give the client a specific list. Not a general warning about "don't change things," but a named list. "These are the exact property names this automation depends on. If any of these get renamed, the automation breaks. Before renaming anything in this database, check this list first."
It's not a perfect solution but it works better than you'd think. The specific list is what matters. "Don't rename things" gets ignored. "Here are the seven exact property names" gets checked.
The other thing I do is bring it up on the handoff call, not just in the docs. People remember things they heard explained. They don't always remember things they read in documentation a month ago.
Mistake 2: Using the Wrong Property Type
This one happens at setup, before the automation even exists. And it's tricky because the property type that feels natural for human use is often the worst one for automation.
The most common version of this: someone builds a Notion CRM and stores pipeline stage as a plain Text property. "I'll just use Text, it's flexible, I can type anything I want." That's true. And that flexibility is exactly what causes the problem.
When n8n tries to filter records where Stage equals "Qualified," it works inconsistently. Text fields don't have defined options. One person types "Qualified," another types "qualified," another types "QUALIFIED," another types "Qualifed" because they typo'd it once and never fixed it. Now your filter is missing records it should be catching.
Select properties don't have this problem. The options are fixed. "Qualified" in a Select field is always "Qualified." You can filter on it reliably from n8n, you can use it in conditions, you can use it as a trigger. Text is for humans who want flexibility. Select is for systems that need consistency.
The write-only version of this mistake
There's a related version that trips people up in a different way. Someone designs a database with a Rollup property that computes a value they want, then tries to have n8n write to that Rollup from an external trigger.
Rollups are computed. Formulas are computed. You can't write to them. n8n will throw an error, or in some cases silently do nothing, depending on how the write is configured. The value has to come from the source properties the Rollup or Formula is pulling from. You can't bypass the computation by writing directly to the output.
Same goes for Formulas. If you want n8n to set a "Priority Score" based on some external data, you need an actual Number or Select property for that. You can have a Formula column that displays it nicely, but the writeable value needs its own property.
The fix
Before building a database that an automation will touch, spend a few minutes mapping out which properties need to be written to, filtered on, and read from. That map determines which types to pick. It's a ten minute exercise that prevents a lot of retrofitting later.
The general rule: if a machine needs to write it, use a writable property type. If a machine needs to filter on it with defined values, use Select or Status, not Text. If it's just display or computation, Rollup and Formula are fine.
Mistake 3: Restructuring a Database That an Automation Depends On
Relations feel more permanent than properties. You set them up once, you mostly forget about them. Which is exactly why this mistake is so easy to make.
Here's a scenario I've seen play out. A team has a Projects database. Their Clients database has a relation to Projects. An automation in n8n creates new client records and links them to the relevant project using that relation. This all works fine.
Six months later, the Projects database has grown unwieldy. Someone decides to split it into "Active Projects" and "Archive Projects" to make it cleaner. They move all the old records to Archive Projects and create a fresh Active Projects database. Makes sense from a workspace management perspective.
But the relation in the Clients database still points at the original Projects database. And the automation in n8n is still configured to link records to Projects, not Active Projects. Every new client record created from that point has a broken or missing relation. The automation runs fine. No errors. But the data structure is silently wrong.
This one is particularly painful because it's not just an automation issue, it's a data issue. Existing records might have dangling relations. New records are getting linked to the wrong place or not linked at all. And it might be weeks before anyone notices because the records look complete otherwise.
Why this is easy to miss
When you're restructuring your Notion workspace, you're thinking about Notion. You're thinking about the database you're splitting, the records you're moving, how the new structure will look for your team. You're not thinking about what's happening three steps away in an n8n workflow that uses a relation to that database.
The connection isn't visible from inside Notion. There's nothing telling you "four automations depend on this database." You're just reorganizing your workspace.
The fix
Treat the databases your automations point to as load-bearing walls. Before you restructure, archive, split, or rename any database, ask one question: does any automation have a relation to this, or write to this directly? That's a 30 second check that prevents hours of debugging.
If you do need to restructure a database an automation depends on, update the automation before or immediately after you restructure. Don't let time pass between the two.
Mistake 4: Trying to Use Formula Properties as Automation Inputs
This one catches people who know Notion pretty well. They've built sophisticated formulas, they understand how the formula editor works, they've got computed properties doing real work in their database. So when they start adding n8n, it's natural to want those formula values to be part of the automation logic.
The problem is formulas are read-only from the API. n8n can read a formula value, but it cannot write to one. If you try to update a formula property from a workflow, you'll either get an error or the write will silently do nothing. The formula keeps computing what it computes. You can't override it from the outside.
The scenario I run into most: someone has a "Composite Score" formula that combines a few properties. They want an n8n workflow to set that score based on data coming in from a form or a CRM. So they configure the workflow to write to the Composite Score property. It doesn't work. They check the execution log. Looks fine. They check Notion. The score hasn't changed. They spend an hour trying to figure out why before someone tells them formulas are read-only.
n8n returns 200 OK. Notion ignores the write. The formula value stays at 48.
The subtler version
There's a less obvious version of this too. Some people build filters in n8n that target formula outputs, expecting them to behave the same way Select or Text properties do in filter conditions. This can work in some cases and behave strangely in others, depending on the formula complexity and the filter type.
Formula values aren't indexed the same way discrete property options are. If you're building automation logic that depends on filtering by a formula output, you're likely going to hit edge cases.
The fix
If an automation needs to write a value, that value needs to live in a real, writable property. Number, Text, Select, Date, whatever fits the data. The formula can still exist for display purposes if you want. But the source of truth has to be something n8n can actually write to.
If you need to filter on something in n8n reliably, use a real property, not a formula output. You can always have a formula that computes a display value from the real property.
The Thing All Four of These Have in Common
Every one of these mistakes comes from the same root cause. The database was designed for human use first, and automation was added later as an afterthought.
That's not a criticism. Most Notion databases start that way because most teams start using Notion before they start using automation. You build what you need right now. The database makes sense for how your team works. Then six months later you want to add n8n and you're retrofitting automation onto a structure that wasn't designed with it in mind.
Property names that make sense to you are not necessarily stable or specific enough for a machine. Flexible Text properties are great for humans who want to type whatever. They're a mess for automations that need to filter reliably. Database structures that feel natural for your team workflow might have relational dependencies that automations are now hard-wired to.
The fix for all of it is the same: before you add automation to an existing database, spend some time looking at it through the lens of the automation. What would break if a property got renamed? What would break if a relation target changed? Are there formula properties that look like they should be writable but aren't? Are there Text properties where automation will need defined options?
You don't have to redesign everything. But you do need to understand where the fragile points are before you build something that depends on them.
Before You Build the Automation, Run Through This
These are the six things I check now before touching n8n on any existing Notion database.
None of this is complicated. It's mostly just slowing down for ten minutes before you build and asking the right questions. The mistakes above aren't hard to avoid once you know they exist. They're hard to avoid when you're moving fast and nobody has told you where the edges are.
Notion databases feel permanent and stable because they usually are, for human use. Automation adds a layer of dependency that most people can't see from inside Notion. The goal is to make those dependencies visible before they become problems.
