Your Odoo automations are quietly breaking things

Odoo automation is one of the best reasons to run an ERP at all: the follow-up email that sends itself, the invoice that posts on schedule, the stock alert that fires before you run out. Set up well, it quietly does the repetitive work your team used to do by hand. Set up badly, the exact same tools send a customer the same reminder five times, lock a record in a loop, or run a heavy job every minute of the working day until everyone complains the ERP is slow. The tools are not the problem - the confusion between them is. Odoo has three related automation features that people mix up constantly, and knowing which one to reach for, and how to scope it, is the difference between automation that helps and automation that hurts.

The three tools, and what each is for

Almost every Odoo automation mistake starts with reaching for the wrong tool, so get the distinction clear before you build anything.

• Scheduled actions (cron). These run on a timer, independent of anything a user does - every hour, every night, every Monday. Use them for time-based work: send a digest, expire old quotations, generate a recurring invoice, sync a feed. The key setting is the interval, and it is the one people get wrong most often.
• Automation rules. These fire in response to a record event - a record is created, a field changes, a stage moves. Use them for reactive work: when a lead is marked won, create a project; when an invoice is validated, notify accounts. The trigger condition is everything here; too broad and it fires constantly.
• Server actions. These are the reusable block of logic - send an email, update fields, create a linked record - that a scheduled action or an automation rule actually runs. A cron or a rule is the trigger; the server action is the work. Keeping them separate is what lets you reuse and test the logic on its own.

Said plainly: a scheduled action answers "run this on a timer", an automation rule answers "run this when something changes", and a server action answers "here is what to run". Choose the trigger by asking whether the work is time-based or event-based, then attach the server action that does the job.

Where scheduled actions go wrong: the interval

The single most damaging mistake is setting a cron interval too tight. A job set to run every minute, doing real work each time, competes with your users for the same database and CPU all day long - and it is a classic self-inflicted cause of a slow system, the same family of problem we break down in why your Odoo is slow. Ask what the job genuinely needs: a daily digest does not need to run every minute, and a nightly sync should run at night. Schedule heavy work for off-hours so it never collides with people trying to do their jobs. Give long-running crons room to finish before the next fire, so two copies never overlap and step on each other. And prefer a job that processes a bounded batch each run over one that tries to sweep the entire table every time - the bounded version stays fast as your data grows, the unbounded one gets slower every month until it times out.

Where automation rules go wrong: loops and over-firing

Automation rules cause a different class of failure, and it is quieter. The first trap is the self-trigger loop: a rule fires when a record is updated, and its action updates the same record, which fires the rule again. Even when Odoo guards against the simplest version, a chain of rules writing to each other can ripple in ways no one predicted. The second trap is over-firing: a rule set to run on every write, or with a condition too broad, does real work on changes that should not concern it - so an email that should send once on "order confirmed" sends every time anyone touches the order. The discipline is to scope tightly. Trigger on the specific change you mean - a stage moving to a particular value, not any update - and add a condition so the action only runs when it truly should. Make the action idempotent wherever you can, so if it does fire twice, running it again causes no harm rather than a duplicate. Test what happens on an edit, not just on creation, because edits are where the surprises live.

Building automations that stay safe

The teams whose Odoo automation never bites them all work the same way. They design the trigger first - is this time-based or event-based - and pick cron or an automation rule accordingly. They scope hard: a specific condition, a specific stage, a bounded batch, never "on every write" or "sweep everything". They make actions idempotent so a re-run is safe, and they log what an automation did so a wrong result can be traced instead of guessed at. Crucially, they test in a copy of the database before anything touches live data - trigger the event, watch what fires, confirm it ran once and did the right thing. Automations also run with real permissions and can change data across the system, so who and what they can touch matters; the same care you put into Odoo access rights and record rules applies to what an automated action is allowed to do. This is exactly the kind of thing we get right during a proper Odoo implementation, and why bolting automations on afterwards without a plan so often ends in a cleanup.

Frequently asked questions

What is the difference between a scheduled action and an automation rule?

A scheduled action runs on a timer regardless of what users do - every hour, every night - so it suits time-based work like digests and recurring invoices. An automation rule runs in response to a record event, such as a field changing or a stage moving, so it suits reactive work like notifying a team when an order is confirmed. Ask whether the work is triggered by the clock or by a change; that answer tells you which one to use.

Why is my automation firing more than once?

Usually because the trigger is too broad or the action re-triggers the rule. A rule set to run on every write fires on changes you never intended, and a rule whose action updates the same record can set itself off again. Narrow the trigger to the specific change you mean, add a condition so it only runs when it truly should, and make the action idempotent so even a double-fire does no harm. Then test by editing a record, not just creating one.

Can a scheduled action really slow down Odoo?

Yes, and it is common. A cron set to run every minute doing real work competes with your users for the same CPU and database all day. Heavy jobs scheduled during business hours make the whole system feel sluggish exactly when people need it. Give each job an interval matched to what it actually needs, run heavy work off-hours, and process a bounded batch per run rather than sweeping the entire table every time so the job stays fast as data grows.

Do I need code to build Odoo automations?

Often not. Scheduled actions, automation rules, and many server actions can be configured through the interface for common tasks - send an email, update a field, create a linked record. Code becomes necessary only when the logic is genuinely complex or specific to your process. Even then, the safe-design rules are identical: pick the right trigger, scope it tightly, keep the action idempotent, and test in a copy first. The tool being no-code does not make a badly scoped automation safe.

The short version: Odoo automation is powerful precisely because it acts without a human watching, which is also why a badly scoped one does damage quietly. Learn the three tools and reach for the right one, schedule cron for what it truly needs and keep it off business hours, scope automation rules to the exact change, make actions idempotent, and test in a copy before you go live. Do that and automation gives you back hours instead of handing you a cleanup.