How Odoo Automation Rules Work: Triggers, Actions and Examples in Odoo 19

Repetitive updates, reminders, assignments, and notifications can slow daily operations and create inconsistent data across Odoo ERP applications such as CRM, Sales, Accounting, Project, and Subscriptions. Odoo automation rules help businesses handle these recurring workflows with greater consistency and less manual intervention.

This guide explains the core components of Odoo automation rules in Odoo 19, how to configure them, where they can be applied, and how to test and manage them safely.

What Are Odoo Automation Rules?

Odoo automation rules are configurable instructions that execute predefined actions when a specific event occurs in the database. They help businesses handle recurring tasks consistently without requiring users to perform every update, notification, or follow-up manually.

The interface generally refers to these configurations as Automation Rules, while older resources may use the term Automated Actions. Both describe the same event-driven automation concept supported by Odoo’s base_automation framework.

Each rule follows a simple sequence:

Trigger → Conditions → Actions

The trigger starts the evaluation, conditions determine whether the relevant record qualifies, and actions define the resulting response. Because rules operate on Odoo records, they can support connected workflows across installed applications while preserving a consistent data flow.

Key Components of an Odoo Automation Rule

Every automation rule contains four core elements: a model, a trigger, optional conditions, and one or more actions. Each element controls a different part of the workflow, from identifying the relevant business record to determining the final system response.

Model

The model defines the type of Odoo record on which the automation rule operates. Examples include a CRM lead, sales order, customer invoice, project task, helpdesk ticket, or subscription.

At the technical level, these records belong to models such as crm.lead, sale.order, account.move, and project.task. An automation rule is created for one primary model, although it can use relational fields to access connected records.

The selected model determines which fields, triggers, conditions, and actions are available. Choosing the correct model is therefore essential: a rule created for sales orders cannot directly respond to changes that occur only on customer invoices.

Trigger Types

A trigger defines the event that starts an automation rule. The options available depend on the selected model and installed Odoo applications. Odoo 19 groups triggers into five main categories:

• Values Updated: Starts a rule when a supported field receives a specific value, such as a CRM stage, assignee, status, or tag.
• Email Events: Responds when an email is sent or received in connection with an Odoo record.
• Timing Conditions: Runs relative to a date field, record creation, or the latest update. It can support reminders, escalations, renewals, and other time-dependent processes.
• Custom: Covers events such as record creation, creation and editing, deletion, or a manual field change in the form view. The On UI change option works before the record is saved and is limited to the Execute Code action.
• External: Starts the rule when Odoo receives a webhook from another system or application.

A trigger identifies when Odoo should evaluate the rule. It does not, by itself, determine whether every affected record should receive the configured actions.

Conditions and Domain Filters

Conditions narrow the scope of an automation rule so that it processes only relevant records. Odoo uses domain filters to evaluate field values, statuses, relationships, and other record attributes.

The main condition fields serve different purposes:

• Before Update Domain evaluates the state of an existing record before the triggering update. It is not evaluated when a new record is created.
• Apply on evaluates the record after the trigger event.
• When updating identifies the fields whose modification can start the rule.
• Additional conditions may appear depending on the selected model and trigger.

For example, a rule designed to detect when an email address is added for the first time can require the email field to be empty in the Before Update Domain and populated in the Apply on domain. This separates a new email entry from a later correction to an existing address.

Precise filters reduce unnecessary processing and prevent actions from being applied to records outside the intended workflow.

Action Types

Actions define what Odoo does after the trigger occurs and all required conditions are met. Available actions can be grouped by their operational purpose:

• Data actions: Update a field, calculate a value, assign a sequence, create a record, or duplicate an existing record. Odoo 19 can also update supported fields using AI when the required application is installed.
• Workflow actions: Create an activity, assign responsibility, or schedule a follow-up linked to the original record.
• Communication actions: Send an email, SMS, or WhatsApp message, or post content as a message or internal note.
• Follower actions: Add or remove specific contacts or dynamically selected record-related contacts as followers.
• Integration actions: Send selected record data to an external webhook through a POST request. For broader system integration, see this Odoo API guide
• Advanced actions: Execute Python code or combine several child actions through Multi Actions.

How to Create Automation Rules in Odoo 19

Creating an automation rule begins with a defined operational requirement: the event to monitor, the records that qualify, and the response Odoo should perform. Odoo 19 provides several access routes, but each leads to the same core configuration of model, trigger, conditions, and actions.

Access Automation Rules

The most direct method is to open the relevant Odoo application, launch Studio, select Automations, and click New. Starting from the required application automatically places the rule in the context of its underlying model.

Administrators can also activate Developer Mode and navigate to Settings → Technical → Automation → Automation Rules. This centralized view is useful for reviewing and managing rules across different models.

In a grouped Kanban view, such as the CRM pipeline, open the settings menu beside a stage and select Automations. Odoo preselects the corresponding stage-based trigger, which can be changed if the workflow requires different logic.

Configure the Model, Trigger and Conditions

Give the rule a clear name that describes both the event and intended result. Confirm the target model, then select the trigger and complete any related fields, values, dates, or delays.

Apply the domain filters described earlier to capture the intended state transition. Use When updating to restrict execution to the fields that should initiate the rule, preventing unrelated edits from triggering it.

For timing conditions, select the reference date and specify whether the action should run before or after it. For an external trigger, configure the incoming webhook and how Odoo should identify the target record.

Add and Order the Actions

Open the Actions To Do tab and click Add an action. Select the required action type and complete its settings, such as the field value, activity owner, message template, target model, webhook URL, or Python expression.

One Odoo automation rule can execute multiple actions. Actions run in their displayed order, so sequence matters. For example, if an email template uses a field updated by the same rule, the Update Record action must come before the Send Email action. Use the drag handle to rearrange actions when necessary.

Save and Confirm the Rule

Select Save & Close after completing an action or Save & New to add another. Once the automation rule itself has been saved, it can respond to matching events unless it is archived or disabled.

Before leaving the form, verify the model, trigger, domain filters, and action order.

Practical Odoo Automation Rule Examples

Odoo automation rules can support operational workflows across different applications. The most effective rules connect a specific business event with a narrowly defined condition and measurable response.

These examples can be adapted to different approval levels, user roles, business units, or company-specific fields without changing the underlying trigger–condition–action structure.

Odoo Automation Rules in Odoo 19 vs Odoo 18

The core automation framework remains consistent between Odoo 18 and Odoo 19. Both versions use models, triggers, domain filters, and actions to automate record-based workflows. The main differences appear in the available action options and how some capabilities are presented.

The Update with AI option requires the Odoo AI application, while the available fields and triggers still depend on the selected model and installed apps. Businesses upgrading from Odoo 18 should therefore review each existing rule against the Odoo 19 database rather than assuming that every model exposes identical options.

Automation Rules vs Other Odoo Automation Tools

Automation Rules are best suited to record-level workflows initiated by a defined business event. Other Odoo tools may be more appropriate when automation requires reusable logic, recurring batch processing, external data exchange, or complex application behaviour.

These tools are often complementary rather than mutually exclusive. An Automation Rule can invoke a Server Action, use a webhook as its trigger or output, and rely on a Scheduled Action for time-based evaluation.

Use Automation Rules for targeted record events, Scheduled Actions for recurring background jobs, webhooks for cross-system events, and custom modules for complex or business-critical logic.

How to Test, Troubleshoot and Manage Automation Rules Safely

A technically valid rule can still produce incorrect results if its domain, permissions, action order, scheduler, or integration settings do not match the real workflow. Testing should therefore confirm both when the rule runs and when it must remain inactive.

Test the Rule Before Production

Build and validate the rule in a staging or duplicated database containing representative records. Test at least three scenarios:

• A record that meets every condition.
• A record that must be excluded.
• A record that moves from an excluded state into a qualifying state.

Confirm field values before and after execution, the order of multiple actions, assigned users, generated activities, and outgoing messages. Repeat the test using the access rights of the intended business user, not only an administrator account.

For integrations, use test endpoints and non-production credentials. Record the expected and actual result of each scenario before enabling the rule in the live database.

The Rule Does Not Trigger

First, confirm that the rule is active and linked to the correct model. Then check whether the selected event actually matches the trigger configuration.

Review the following areas:

• The record satisfies the Before Update Domain before the change.
• The record satisfies Apply on after the change.
• The changed field is included in When updating.
• The executing user can read and modify the required records.
• Related fields contain the data required by the action.
• The trigger is supported by the selected model.

For On UI change, the field must be changed manually in the form view, and the rule must use Execute Code. Changes made by another automation rule do not activate this trigger.

The Rule Runs More Than Once

Repeated execution commonly occurs when On create and edit monitors too many fields or when When updating is left unrestricted. An action may also update the same field that initiated the rule, creating a recursive loop.

Reduce the trigger scope to the required fields and use Before Update Domain with Apply on to detect a genuine state transition. If a process must run only once, add a status, timestamp, or processed flag that prevents the record from qualifying again.

Also check for overlapping automation rules, integration retries, and custom modules acting on the same model. External operations should use an idempotency key a unique request identifier that prevents the same transaction from being processed twice where retries could create duplicate records or notifications.

Time-Based Actions Run Later Than Expected

A Timing Conditions rule does not continuously monitor the database. It becomes eligible at the calculated execution time and runs during the first scheduled check after that time has passed.

By default, the related scheduled action runs every four hours. If any time-based automation rule uses a delay shorter than 40 hours, Odoo automatically increases the checking frequency so eligible actions run closer to their target time. Execution may still occur later than the exact deadline.

After configuring the timing trigger and delay, save the rule, open Scheduled action, and click Run manually before adding the final actions. This initialises the last-run timestamp and helps prevent retroactive execution on historical records.

Emails or Webhooks Are Not Delivered

For email failures, check the recipient field, email template, sender address, outgoing mail configuration, and mail queue. A successful rule execution does not guarantee delivery if the message lacks a valid recipient or the mail server rejects it.

For webhooks, verify:

• The webhook URL is correct and the destination endpoint accepts POST requests.
• The fields included in the payload.
• Authentication or secret handling.
• Target record identification.
• HTTP response codes and timeout errors.
• Webhook call logs, if logging is enabled.

Treat an incoming webhook URL as confidential. If it becomes exposed, rotate the secret and update the sending system. The receiving endpoint should also handle retries without creating duplicate transactions.

Maintenance and Governance Checklist

Automation rules should be managed as part of the ERP operating model rather than treated as isolated shortcuts.

• Use names that identify the event and intended outcome.
• Document the rule’s purpose, owner and affected model.
• Keep domain filters as narrow as practical.
• Avoid duplicate rules covering the same transition.
• Restrict Python code to requirements that standard actions cannot handle.
• Assign only the permissions required for execution.
• Archive obsolete rules instead of leaving them active.
• Review dependencies after changing fields, models or installed applications.
• Retest critical rules during an Odoo upgrade.
• Monitor logs, processing time and unexpected record volume.

A maintained rule library makes automation easier to audit, troubleshoot and transfer between system owners.

Build Safer Automated Workflows with Odoo

Reliable Odoo automation depends on a valid business process, precise record targeting, and clear ownership. Each rule should remain understandable, traceable, and maintainable after the original configurator has moved on.

A1 Consulting helps businesses assess workflows, configure Odoo Enterprise, design integrations, validate automation logic and support users after go-live. The approach prioritises standard Odoo capabilities where they meet the requirement, while reserving custom development for confirmed operational gaps.

Whether the objective is faster CRM follow-up, controlled approvals, subscription renewal, finance escalation or cross-system communication, the right design keeps automation useful, traceable and ready to scale.

Contact A1 Consulting to assess which workflows can be automated without adding unnecessary complexity or operational risk.

Sally N.

BDM - Partner and Alliance

With over 7 years of experience in ERP advisory, Sally has worked closely with SMEs across Malaysia to streamline operations and drive digital transformation. Her deep understanding of business processes and hands-on approach have made her a trusted advisor to many growing companies. Through this blog post, Sally aims to share practical insights and real-world lessons drawn from her implementation experience, offering guidance to businesses navigating their own ERP journey.