The automation that ran perfectly last week is not broken so much as quietly switched off, usually by a small edit you did not connect to it.
Notion database automations feel magic until they stop, and when they stop they rarely announce it. No error, no red banner, just a task that never gets its status, a page that never lands in the right database, a reminder that never sends. Nine times out of ten the culprit is a template edit that severed the link the automation depended on. Here are the ten mistakes that most often kill a Notion automation, the reason each one breaks it, and the fix that brings it back.
Bottom Line First
- Most dead automations trace to an edit that renamed, retyped, or rescoped the exact property or view the automation was watching.
- Notion deliberately blocks automations from triggering other automations, so a chain that depends on one rule firing another will silently fail.
- The fix is almost always to reopen the automation, repoint it at the current property or view, and test it with a real change rather than assuming it still works.
Table of Contents
Why a working template suddenly goes quiet
A Notion automation is a rule bolted to specifics: this property, this option, this view, this database. It has no common sense about your intent, so when you rename a field or convert a property type, the automation does not adapt, it just stops matching anything. Because the rule still exists and looks fine in the panel, the failure is invisible until you notice the outcome never happens. Treat every one of these mistakes as a broken reference rather than a bug, and the fix becomes obvious.
1. Expecting one automation to trigger another
This is the big one, and it is by design. Notion states plainly that database automations cannot be triggered by other automations, a guardrail against infinite loops. So if Automation A edits a status and you built Automation B to fire when that status changes, B will never run, because the change came from an automation and not a person. Chains like this fail silently. The fix is to collapse both steps into one automation where possible, or to use an external tool such as Zapier watching the database when you genuinely need multi-step chaining.
2. Renaming the property a trigger depends on
Automations point at a property by identity, and renaming that property can sever the link the trigger or filter relied on. The rule keeps showing in the panel but no longer resolves to a live field, so nothing fires. If an automation went quiet right after you tidied up field names, open it, and repoint the trigger and any filters at the renamed property. Renaming is fine, but the automation needs to be told about it.
3. Changing a property’s type after the fact
Converting a property from, say, text to select, or select to status, changes what the automation can read and write. Filters that compared against the old type stop matching, and actions that set a value can no longer write to it. This is one of the sneakiest breaks because the property still exists under the same name. After any type change, revisit every automation that touches that property and rebuild its condition and action against the new type.
4. Renaming the status or select option a filter checks
An automation filtered to fire when status equals “In progress” depends on that exact option existing. Rename it to “Active” and the automation still runs, but the filter now matches nothing, so the effect never happens. This looks especially baffling because the automation appears healthy. Whenever you rename or reorganize status and select options, audit the automations that reference the old label and update the filter to the new one.
5. Duplicating the template without reconnecting it
When you duplicate a database or a whole workspace template, the copy is a new database, and automations that act across databases can still point at the original. So your shiny duplicate looks complete while its automation is quietly writing to, or watching, the old copy. After duplicating, open each automation in the new database and confirm that every trigger and action references the copy, not the source you cloned from.
6. Confusing a button with a database automation
Notion has two different things that feel similar: a button, which only runs when someone clicks it, and a database automation, which runs on a trigger like a page being added or a property changing. If you built your logic into a button and expected it to fire on its own, it never will, because a button waits for a click. Decide whether the action should be manual or automatic, and move the logic into a database automation if you need it to run without you.
7. Scoping the trigger to one view instead of the database
When you create an automation, you can set it to run on the whole database or on a specific view. Pick a view, and pages added or changed outside that view will not trigger the rule. This bites when a template ships with a filtered view and you forget the automation is bound to it. If some rows fire the automation and others do not, check whether the trigger is scoped to a view, and widen it to the entire database unless you truly want the narrower scope.
8. Expecting formula and rollup updates to count as edits
A property that changes because a formula recalculated or a rollup refreshed is not the same as someone editing that property, and an automation waiting for an edit may never see it. People build a rule expecting a formula flip to trigger it, then wonder why nothing happens. Where you can, trigger the automation off the underlying change a person actually makes, rather than off a calculated value that updates on its own.
9. Expecting the automation to fix rows that already exist
Automations act on triggers going forward, so turning one on does not sweep back through the pages already sitting in your database. The rows created before the automation existed keep their old values, which reads like the automation is broken when it is simply waiting for new triggers. To bring old rows into line, make a qualifying change to each one, or handle the backlog with a quick manual pass, then let the automation cover everything from there.
10. Breaking a relation the action points to
If an automation creates or updates a page in a related database, it depends on that relation staying intact. Unlink the relation, delete the related database, or rebuild it during a template cleanup, and the action loses its target and fails. When you restructure linked databases, trace every automation whose action reaches into another database and reconnect it to the current relation so the target still exists.
Frequently Asked Questions
Why is my Notion automation not firing?
The most common reason is a template edit that broke the automation’s reference: a renamed property, a changed property type, or a renamed status option the filter checks. The rule still looks fine but no longer matches anything. Notion also blocks automations from triggering other automations, so a chained setup fails by design. Open the automation and repoint it at the current field, then test with a real change.
Can one Notion automation trigger another?
No. Notion prevents database automations from being triggered by other automations to avoid infinite loops. If your workflow relies on one rule setting a value that a second rule watches, the second rule will never fire. Combine the steps into a single automation where you can, or use an external tool like Zapier or Make to watch the database and run multi-step chains.
Do Notion automations run on existing rows?
No. Automations act on triggers from the moment they are active, so they do not process rows that already existed. Older pages keep their previous values until something triggers the rule for them. To update the backlog, make a qualifying change on each old row or run a manual pass, after which the automation handles new activity automatically.
Why did my automation stop after I duplicated the template?
Duplicating creates a new database, and automations that act across databases can still reference the original copy rather than the duplicate. The new template then looks complete while its automation reads from or writes to the old one. Open each automation in the copy and confirm every trigger and action points at the new database.
Does renaming a property break a Notion automation?
It can. Automations depend on the specific property, option, or view they were built against, so renaming a field or a status option can leave the rule matching nothing even though it still appears active. After renaming anything a rule depends on, reopen the automation and update its trigger, filter, and action to the new names.
Practical Takeaway
A Notion automation that stopped is rarely a real fault, it is a broken pointer left behind by an edit. Before you rebuild anything, retrace the last few changes to the template: a renamed field, a retyped property, a renamed status, a duplicated database, or a chain that Notion was never going to allow. Reopen the automation, repoint it at what exists now, and test it with a genuine change so you know it fires. For more workspace fixes and comparisons, browse Wayodd’s Computing section, and if you are weighing tools, see our take on Notion alternatives that work offline.