Automation without a developer

Most people assume automating something in Odoo needs code. Often it does not.

Automated actions are rules you configure in the interface. When something happens to a record, Odoo does something in response — sends an email, updates a field, creates a task, notifies a manager.

No module, no deployment. Configured once and it runs from then on.

The useful part is knowing what they can do well, and where they stop.

The two kinds

Odoo has two mechanisms, and they solve different problems.

Automated actions react to something happening. A record is created, a field changes, a condition becomes true.

Scheduled actions run on a timer. Nightly, hourly, weekly — regardless of whether anything happened.

A useful way to choose: if the trigger is an event, use an automated action. If the trigger is the passage of time — “invoices now 30 days overdue” — use a scheduled one.

What triggers an automated action

The common triggers:

• On creation — a new record appears
• On update — a record is edited
• On creation or update — either
• When a field changes to a specific value — a stage moves to Won, a state becomes Done
• Based on a time condition — a number of days after a date field

You can add a filter so the rule only applies to records matching a condition. High-value orders. One customer category. A specific warehouse.

Use filters generously. A rule with no filter runs on everything, which is both slower and more likely to do something you did not intend.

What it can do

The actions available without code:

• Send an email using a template
• Update a field on the record
• Create a new record — an activity, a task, a follow-up
• Add followers so people are notified of changes
• Send a notification to a user
• Trigger another automated action

For most everyday automation this is enough.

Where they stop

Four limits worth knowing before you commit to solving something this way.

Complex logic. Multi-step conditions, calculations across several records, anything involving data from unrelated models. If describing the rule takes a paragraph with several “unless” clauses, it belongs in a module.

Volume. Automated actions are fine at normal volume. A rule firing on every line of a nightly import of fifty thousand records is a performance problem.

Testing. There is no built-in test-then-release step. An automated action applies immediately to your live system.

Traceability. Like Studio changes, these are made by clicking. Nothing records why the rule exists or who asked for it.

That last one is the quiet problem, and it deserves its own section.

The mess that builds up

A pattern worth recognising, because it is common.

A company adds a few automated actions. Sensible ones. Over two years, dozens accumulate — added by different people, for reasons nobody wrote down.

Then someone reports that customers are getting duplicate emails, or that a field keeps changing back on its own. Now somebody has to work out which of forty rules is responsible, with no documentation and no history.

Three safeguards:

Name them properly. Not “Automation 4”. Something that says what it does — “Notify manager: order over 50k confirmed”.

Keep a written log. What, when, why, who asked. A shared document is enough.

Review every six months. Deactivate what is no longer needed. Rules outlive the situations that created them.

Before you build one

Four questions.

Does a setting already do this? Odoo has built-in follow-up levels for overdue invoices, activity scheduling in CRM, and reordering rules in inventory. Check before automating manually.

What happens if it fires wrongly? An email to the wrong customer is embarrassing. A field updated wrongly across thousands of records is worse. Consider the blast radius.

How will we know it is working? And more importantly, how will we know if it stops?

Who owns it? Somebody should be able to explain it in a year.

Testing one safely

Two habits that prevent most accidents.

Test in a staging database first — a neutralised copy of production, so test emails do not reach real customers.

Start with a narrow filter. Apply the rule to one customer or one category first. Watch it for a week. Then widen it.

The temptation is to switch it on for everything immediately. The cost of that going wrong is much higher than the week of patience.

When to use code instead

Move to a custom module when:

• The logic needs more than a couple of conditions
• It runs at high volume
• You need it tested before it reaches production
• You need a record of what changed and why
• It has to talk to another system

A rough guide: if you would be uncomfortable explaining the rule to an auditor from memory, it should be in code where it is documented and reviewable.

The short version

Automated actions are genuinely useful and underused. Reminders, alerts and follow-ups are exactly what they are for, and none of it needs a developer.

The risk is not technical. It is accumulation — dozens of undocumented rules that nobody can untangle.

Name them well, write down why, filter them narrowly, and review them twice a year. That is the whole discipline.