Automation has always been the quiet promise behind Odoo Studio. The idea was simple: let business users customize their ERP without waiting in a developer queue. In practice, though, Studio’s automation tools lagged well behind its form and view editors. Building anything beyond a basic “send email when record changes” rule meant falling back to the technical settings menu and wrestling with server action configurations that were clearly designed for developers.
Version 20 changes that equation. Odoo has rebuilt Studio’s entire automation section around a visual workflow builder that handles event-based triggers, scheduled actions, multi-step chains, and conditional branching — all without writing a line of Python.
The Old Way Was a Dead End for Non-Developers
In previous versions, Studio let you create basic automated actions through a simplified form: pick a trigger event, set some field values, optionally send an email. Anything more complex — chaining multiple actions, running automations on a schedule, or evaluating conditions before deciding which path to take — required navigating to Settings, Technical, then Automated Actions, where the interface assumed you understood Odoo’s server action model.
That gap meant Studio served two audiences poorly. Power users who wanted sophisticated workflows couldn’t build them visually. Developers who could handle the technical menu didn’t need Studio in the first place. The rebuilt automation engine in version 20 closes that gap by bringing the full power of Odoo’s automation framework into a visual interface that doesn’t sacrifice capability for simplicity.
Three Trigger Types Replace the Single Event Dropdown
The most visible change is how automations start. Studio now presents three distinct trigger categories instead of the old single-select dropdown that mixed everything together.
Event-based triggersfire when something happens to a record: creation, modification, deletion, or a specific field changing to a particular value. These work the way Studio’s triggers always have, but the configuration is now clearer about exactly which fields and values should activate the rule.
Scheduled triggersrun on time-based intervals — every hour, once a day, weekly — or relative to a date field on the record. A subscription renewal reminder that fires 30 days before the expiration date is now a visual configuration rather than a cron job definition. The builder surfaces the underlying ir.cron model without exposing its raw technical interface.
Condition gates are the genuinely new piece. Instead of baking filter logic directly into the trigger definition, conditions now sit as their own step in the workflow. A trigger fires, the condition gate evaluates a domain filter or boolean check, and the workflow branches accordingly. This separation means one trigger can lead to different action chains depending on the state of the record when the automation runs.
Multi-Step Chains Finally Work Without Code
Previous Studio versions effectively limited automations to a single action: update some fields, or send one email, or create one related record. Chaining those together required either a “multi-action” server action configured in the technical menu or a custom Python script.
The new builder lets users drag action blocks into a sequential chain directly in the visual interface. An incoming support ticket can trigger a workflow that first assigns it to a team based on the category field, then sends an acknowledgment email to the customer, then creates a linked task in the project module — all configured as individual steps in a single automation rule.
Each step in the chain can be one of five action types: update an existing record, send a notification (email, SMS, or internal message), create a new record on any model, execute a Python snippet for edge cases, or nest another multi-action block for deeper branching. The execute-code option is there as a safety valve, but the visual actions cover the vast majority of what business users actually need.
The Server Action Framework Stays Under the Hood
This isn’t a parallel automation system that happens to live in Studio. Every automation rule created through the visual builder generates standard base.automation records backed by ir.actions.serverentries — the same technical primitives that developers use when writing automation rules in Python or XML.
That architecture decision matters for two reasons. First, rules built in Studio and rules built by developers coexist seamlessly. A developer can refine a Studio-created automation in code without starting over, and a power user can inspect what a developer built through the visual interface. Second, it means Studio automations get the same reliability guarantees — transaction handling, error rollback, audit logging — as every other server action in the system.
Scheduled Actions Get a Proper Home
Scheduled automations have historically been one of Odoo’s more confusing features. The ir.cron model is powerful but was buried in the technical settings menu with minimal UI guidance. Most administrators discovered it by accident or through Stack Overflow answers.
Studio now treats scheduled actions as first-class citizens. The builder presents interval configuration — frequency, start time, next execution date — alongside the action chain, so users can see the complete picture: what runs, when it runs, and what it does when it runs. The relative date trigger is particularly useful for businesses with deadline-driven workflows. An invoice payment reminder that sends three days before the due date, escalates to the sales manager on the due date, and flags the account as overdue three days after can be configured as a single multi-step scheduled automation.
What This Means for the No-Code Bet
Odoo has been making increasingly aggressive moves toward no-code customization. Studio can already build custom apps, redesign forms, add computed fields, and generate PDF reports. The automation engine was the last major gap — the one feature area where Studio users regularly had to escalate to a developer.
With this update, a business analyst can now build a complete custom workflow from trigger to action chain to scheduled follow-up without writing code or leaving the Studio interface. That doesn’t eliminate the need for developers — complex integrations, performance-sensitive automations, and anything touching the ORM at scale still belong in code. But it does shrink the category of requests that land on a developer’s desk, which for organizations running lean technical teams is the point.
The Competitive Angle
Salesforce Flow, Microsoft Power Automate, and Zoho’s Deluge scripting engine all serve the same need: letting non-developers build business logic. Odoo’s version has a structural advantage in that the automation builder and the data it acts on live in the same application. There’s no connector configuration, no API mapping, no authentication layer between the automation engine and the business data. A Studio automation rule that moves a CRM lead to a new stage, sends the assigned salesperson a notification, and creates a follow-up task in the project module is operating directly on the same database records with the same access controls.
Whether that advantage translates to actual adoption depends on execution. The visual builder needs to stay fast as automation rules get complex, the condition gate needs to handle real-world filter logic without confusing non-technical users, and the scheduled action interface needs to surface failures clearly when a cron job doesn’t run as expected. The architecture is sound. The interface will determine whether it delivers.