Odoo Automated Actions and Scheduled Actions Without Code

Odoo can automate a lot of routine work without a developer: assigning follow-ups, sending emails, updating fields, and running jobs on a timer. The tools are automation rules (often still called automated actions), server actions, and scheduled actions. This guide explains what each one does, where each stops being “no code,” and how to avoid the mistakes that cause trouble later.

The short answer

• Automation rules react to something happening to a record (created, updated, a date arrives, an email comes in) and then run one or more actions.
• Server actions are the “what to do” part: update a record, create a record, send an email, run Python, and so on. They can also be run by hand from a button or menu.
• Scheduled actions are timers. They run a piece of work every X minutes, hours, days or months, regardless of what users are doing.

Most simple business rules (for example, “when a quote is confirmed, create a follow-up activity for the account manager”) need no code at all. The moment you need real logic, you are writing Python, and that changes the maintenance picture.

Automation rules: trigger, conditions, actions

According to the Odoo documentation on automation rules, a rule is made of a trigger, optional conditions, and one or more actions.

Trigger categories include:

• Values updated: a tag is added, or a field gets a given value.
• Email events: an email is received or sent.
• Timing conditions: based on a date field, after creation, or after last update, with a delay (a negative delay runs the action before the date).
• Custom: on save, on deletion, or on UI change.
• External: triggered by an outside system through a webhook.

Conditions let you narrow it down. A “before update” domain checks the record before the change, and extra conditions check it after. These are what stop a rule from firing on every record in the system.

Actions you can attach, per the same documentation, include updating a record, creating an activity, sending an email or SMS, sending a WhatsApp message (this needs a template), adding or removing followers, creating a record, executing code, sending a webhook notification, and running existing actions. When you attach several, they run in the order you define.

Server actions: the building blocks

In technical terms, the Odoo developer reference for actions describes server actions (ir.actions.server) with four main types:

Type	What it does
Execute code	Runs Python from the code field
Create record	Creates a record in another model from field values you define
Update record	Updates the current record(s) from field values
Multi (execute several)	Runs a list of other actions in sequence

Three of those four are configuration, not programming. Only “execute code” requires a developer’s judgement. Server actions are also reusable: the same one can be called from an automation rule, a button, or the Action menu on a list view.

Scheduled actions: jobs on a timer

Scheduled actions (ir.cron in the technical model) run at a fixed frequency. The developer reference lists the key settings: a name, an interval number and type (minutes up to months), the model, the code or server action to run, the next call time, and a priority.

In developer mode you find them under Settings, Technical, Scheduled Actions. Typical uses:

• Nightly clean-up of stale draft records
• Weekly reminder emails for overdue items
• Periodic syncs with an outside system

Two behaviours are worth knowing about:

• Batching. Long jobs are expected to report progress so the scheduler can process work in chunks. By default it handles up to 10 batches per run, then starts another run if work remains.
• Failure handling. The documentation says three consecutive errors or timeouts cause a run to be skipped and counted as failed, and five consecutive failures spanning at least seven days deactivate the action and notify the database administrator. A broken job can therefore stop quietly unless someone is watching.

Time-based automation rules rely on a scheduler too. By default, the documentation says they are checked every 240 minutes, and for delays under 2,400 minutes the check frequency is recalculated to respect short delays more closely. So “send this one hour after creation” is not instant to the minute. If timing precision matters, test it.

What you can realistically do without code

Good no-code candidates:

1. Follow-up tasks. When an opportunity reaches a stage, create an activity for the owner.
2. Notifications. When an invoice is overdue by a set delay, send a templated email.
3. Field defaults and tagging. When a customer is created in a given country, add a tag or set a salesperson.
4. Approvals nudges. When a purchase order sits unconfirmed past a deadline, create an activity for the manager.
5. Webhook hand-offs. Notify an external tool when a record changes (see the warning below).

Poor no-code candidates: anything involving multi-record calculations, branching logic, external API calls with authentication, or data fixes in bulk. These need code, tests and an owner.

Mistakes to avoid

• No field selected on “when updating field.” The documentation warns that the action may run multiple times per record. Always scope update triggers.
• Rules that trigger rules. One automation changes a field, which fires another automation, and so on. “On UI change” is a special case: the documentation says it works only with execute code and only for manual edits, not when another rule changes the field.
• Webhooks without expertise. The documentation advises against them without technical knowledge, because a misconfigured webhook can disrupt the database and reverting it can take time.
• Hidden Python. Code inside an action lives in the database, not in version control. Document it, and test on a copy before production.
• Forgetting support scope. Odoo’s documentation notes that maintenance of custom code is not included in the Standard or Custom pricing plans and incurs additional fees. If you write code, someone has to own it, including through version upgrades.

Where this lives in your edition

Automation rules are documented as part of the Odoo Studio documentation, which describes building them through Studio. Editions and plans change between versions, so check what your own plan and hosting option include before designing around it.

A sensible way to start

1. List the five most repetitive manual follow-ups your team does.
2. Build one as an automation rule with a narrow trigger and a clear condition.
3. Test it on a copy or a handful of records, and watch the chatter and logs.
4. Only then add the next rule. Keep a simple register: rule name, owner, purpose, date.
5. Review scheduled actions every quarter, and make sure someone is alerted if one fails.

If a rule needs code, treat it like any other customization: write it down, test it, and assign an owner.

Talk it through

If you are unsure whether a process belongs in a no-code rule, a small custom module, or should stay manual, Teknologia Solutions is happy to talk it through with you, with no charge and no obligation. Tell us what you are trying to automate and we will give you an honest view.

---

Sources: Odoo 18 documentation: Automation rules; Odoo 18 developer reference: Actions. Behaviour, defaults and plan inclusions vary by Odoo version and edition, so verify details against the primary sources and your own contract before relying on them.