Most people assume automating something in Odoo needs code. Often it does not.<\/p>\n
Automated actions<\/strong> are rules you configure in the interface. When something happens to a record, Odoo does something in response \u2014 sends an email, updates a field, creates a task, notifies a manager.<\/p>\n No module, no deployment. Configured once and it runs from then on.<\/p>\n The useful part is knowing what they can do well, and where they stop.<\/p>\n Odoo has two mechanisms, and they solve different problems.<\/p>\n Automated actions<\/strong> react to something happening. A record is created, a field changes, a condition becomes true.<\/p>\n Scheduled actions<\/strong> run on a timer. Nightly, hourly, weekly \u2014 regardless of whether anything happened.<\/p>\n FIGURE 1: TWO KINDS OF AUTOMATION<\/p>\n Automated action<\/p>\n Scheduled action<\/p>\n A useful way to choose:<\/strong> if the trigger is an event, use an automated action. If the trigger is the passage of time \u2014 “invoices now 30 days overdue” \u2014 use a scheduled one.<\/p>\n The common triggers:<\/p>\n You can add a filter<\/strong> so the rule only applies to records matching a condition. High-value orders. One customer category. A specific warehouse.<\/p>\n Use filters generously.<\/strong> A rule with no filter runs on everything, which is both slower and more likely to do something you did not intend.<\/p>\n The actions available without code:<\/p>\n For most everyday automation this is enough.<\/p>\n FIGURE 2: AUTOMATIONS WORTH SETTING UP FIRST<\/p>\n Overdue invoice reminder<\/p>\n High-value order alert<\/p>\n Stalled deal nudge<\/p>\n Four limits worth knowing before you commit to solving something this way.<\/p>\n Complex logic.<\/strong> 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.<\/p>\n Volume.<\/strong> 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.<\/p>\n Testing.<\/strong> There is no built-in test-then-release step. An automated action applies immediately to your live system.<\/p>\n Traceability.<\/strong> Like Studio changes, these are made by clicking. Nothing records why the rule exists or who asked for it.<\/p>\n That last one is the quiet problem, and it deserves its own section.<\/p>\n A pattern worth recognising, because it is common.<\/p>\n A company adds a few automated actions. Sensible ones. Over two years, dozens accumulate \u2014 added by different people, for reasons nobody wrote down.<\/p>\n 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.<\/p>\n Three safeguards:<\/strong><\/p>\n Name them properly.<\/strong> Not “Automation 4”. Something that says what it does \u2014 “Notify manager: order over 50k confirmed”.<\/p>\n Keep a written log.<\/strong> What, when, why, who asked. A shared document is enough.<\/p>\n Review every six months.<\/strong> Deactivate what is no longer needed. Rules outlive the situations that created them.<\/p>\n FIGURE 3: AUTOMATION THAT HELPS AND AUTOMATION THAT HAUNTS<\/p>\n Well managed<\/p>\n Accumulated over time<\/p>\n Four questions.<\/p>\n Does a setting already do this?<\/strong> Odoo has built-in follow-up levels for overdue invoices, activity scheduling in CRM, and reordering rules in inventory. Check before automating manually.<\/p>\n What happens if it fires wrongly?<\/strong> An email to the wrong customer is embarrassing. A field updated wrongly across thousands of records is worse. Consider the blast radius.<\/p>\n How will we know it is working?<\/strong> And more importantly, how will we know if it stops?<\/p>\n Who owns it?<\/strong> Somebody should be able to explain it in a year.<\/p>\n Two habits that prevent most accidents.<\/p>\n Test in a staging database first<\/strong> \u2014 a neutralised copy of production, so test emails do not reach real customers.<\/p>\n Start with a narrow filter.<\/strong> Apply the rule to one customer or one category first. Watch it for a week. Then widen it.<\/p>\n The temptation is to switch it on for everything immediately. The cost of that going wrong is much higher than the week of patience.<\/p>\n Move to a custom module when:<\/p>\n A rough guide:<\/strong> if you would be uncomfortable explaining the rule to an auditor from memory, it should be in code where it is documented and reviewable.<\/p>\n 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.<\/p>\n The risk is not technical. It is accumulation \u2014 dozens of undocumented rules that nobody can untangle.<\/p>\n Name them well, write down why, filter them narrowly, and review them twice a year.<\/strong> That is the whole discipline.<\/p>\n Want Odoo to handle the reminders and follow-ups nobody has time for?<\/p>\n Get in touch. We will set up the automations that earn their place and document them so they do not become a mystery.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 \u2014 sends an email, updates a field, creates a task, notifies a manager. No module, no deployment. Configured […]<\/p>\n","protected":false},"author":3,"featured_media":9080,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9079","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\nThe two kinds<\/h2>\n
\n
\n
What triggers an automated action<\/h2>\n
\n
What it can do<\/h2>\n
\n
\n
\n
\n
Where they stop<\/h2>\n
The mess that builds up<\/h2>\n
\n
\n
Before you build one<\/h2>\n
Testing one safely<\/h2>\n
When to use code instead<\/h2>\n
\n
The short version<\/h2>\n