Odoo Automated Actions

Ethan Mercer — Mon, 09 Nov 2026 17:28:10 +0000

Build a CRM follow-up rule around a defined transition and a narrow record filter. Odoo 20 automation rules combine triggers, conditions, and actions.
Check the subscription before installing Studio. Odoo’s Studio documentation says installing it on Standard triggers an upgrade to Custom.
Test repeated edits, missing assignees, and rollback in a copied database. Disabling a rule stops future execution; it does not undo activities or messages already created.
Keep deterministic follow-up separate from model-directed work. The CRM example uses a configured stage condition and predefined actions, with no model making the qualification decision.

Define the Automation Before Opening Studio

Odoo automated actions are rules that execute predefined work when a record event occurs and its configured conditions match. In the Odoo 20 interface and documentation, the feature is described as automation rules. A rule can update a field, create an activity, or perform another supported action.

For Odoo CRM automation, this walkthrough designs an internal follow-up: when an opportunity enters a chosen qualification stage, create a review activity for its salesperson and mark that the follow-up was created. The rule should ignore routine later edits and should not create another activity merely because the opportunity leaves and re-enters the stage.

The example targets an Odoo 20 database with CRM and Studio available, appropriate administrative access, and a copied test environment. It does not assume that Community, every subscription, or an older version exposes the same interface.

Use disposable opportunity records and test users. Keep external messaging and real customer actions outside this exercise.

Confirm the Version and Plan for Odoo Automated Actions

Confirm the database version, hosting arrangement, installed applications, and subscription before configuring the rule. A menu shown in an older tutorial may have a different label or behavior in your database.

The Odoo pricing page lists Studio in the Custom offering and distinguishes environments that support custom development. Check the subscription change identified above against your account’s terms before installing applications. Include any change in continuing costs in the approval decision.

This guide follows the documented Studio route. It does not require a third-party automation module, an external API integration, or a custom Python server action. If those become necessary for a different workflow, assess their hosting and maintenance requirements separately.

Before proceeding, record the version and the configuration in the test database. Identify the administrator who will reproduce the accepted rule in production and the operations owner who will validate its business behavior.

Specify the CRM Follow-Up Contract

Use a written contract to distinguish a qualifying transition from a record that merely remains in the target stage. The following names are example labels to configure in your test database.

Model: Use CRM opportunity records on the Lead model.
Target stage: Select a designated test stage named Qualified.
Trigger field: Watch changes to Stage.
Required assignee: The Salesperson field must be set.
Repeat guard: Add a Boolean field named Qualification Follow Up Created.
Business action: Create an internal To Do activity for the opportunity’s salesperson.
Guard update: After creating the activity, set Qualification Follow Up Created to true.

Use the field selector to target the correct record and relation. Stage names and record identifiers are database-specific; do not copy a numerical stage ID from another database.

The Boolean records the intended once-per-opportunity behavior. If the business instead wants a fresh activity on every return to Qualified, that is a different contract and needs different tests. Do not silently reset the marker whenever a stage changes.

The CRM record is the source of truth. This rule does not infer qualification from email content or decide who should own an opportunity.

Create a Narrow Rule in the Test Database

Create the rule from the intended model so its fields and actions apply to CRM opportunities. Odoo documents opening Studio, selecting Automations, and creating a new rule. Available triggers depend on the model.

Open the copied CRM database and an opportunity form. In Studio, create the Boolean repeat-guard field. Confirm it starts false on the disposable records. Record its actual technical name for handover.
Open Automations and create a rule with a descriptive name such as Create Qualified Opportunity Follow Up. Confirm the model is the CRM Lead model used by the opportunity form.
Choose the documented Custom trigger On create and edit. In When updating, select Stage. Odoo warns that omitting the watched fields can cause multiple executions per record.
With developer mode available, configure Before Update Domain so Stage is not the selected Qualified stage. Configure Apply on so Type is Opportunity, Stage is Qualified, Salesperson is set, and Qualification Follow Up Created is false. The type filter keeps ordinary leads outside the example’s scope.
In Actions To Do, add Create Activity. Select the internal To Do activity type, give it a distinctive summary such as Review Qualified Opportunity, and assign it through Dynamic User to the opportunity’s Salesperson. Set an appropriate due interval for the test.
Add an Update Record action after activity creation. Set Qualification Follow Up Created to true. Keep Stage as the watched field; the marker update should not itself be the event the rule watches.
Save the rule and document its purpose, actions, guard, owner, and rollback steps in the available notes. Run the test cases before reproducing it in production.

Odoo distinguishes conditions before the triggering update from those after it. Before Update Domain is not checked when a record is created. A new opportunity created directly in Qualified can therefore match the post-condition. The test contract below treats that as eligible when an assignee exists and the marker is false.

If your business wants existing-record transitions only, use a design that explicitly excludes direct creation and validate it in your installed version. Do not assume the pre-update condition handles creation.

Test Odoo Automated Actions With Disposable Records

Test both the expected action and the absence of unwanted actions. Inspect the opportunity’s activity list and the guard field after each case, rather than treating a successful save as evidence of correct behavior.

Existing opportunity enters Qualified. Move an assigned opportunity from another stage to Qualified with the repeat guard set to false. Expected result: a follow-up activity is created and Qualification Follow Up Created becomes true.
Description changes while the stage stays Qualified. Edit the description without changing Stage. Expected result: no additional follow-up activity.
A processed opportunity returns to Qualified. Move an opportunity whose repeat guard is already true out of Qualified, then back into it. Expected result: no additional follow-up activity.
An unassigned opportunity enters Qualified. Move an opportunity with no salesperson into the target stage. Expected result: no activity and no marker update.
A new opportunity is created directly in Qualified. Create an assigned opportunity in the target stage with the repeat guard set to false. Under the stated contract, it is eligible for a follow-up activity because Before Update Domain is not checked during creation. Confirm the actual execution in the test database.
A non-qualifying record is saved. Save a record that does not meet the configured conditions. Expected result: no follow-up activity and no guard change.

Also test a bulk stage update and any import or integration route your team actually uses. User-interface behavior is insufficient evidence for those routes. Record the observed outcome, user permissions, and resulting activity ownership separately.

The missing-assignee case needs an operating procedure. Under the rule above, assigning a salesperson later does not create a Stage update. Have the operator resolve ownership before qualification, or create a separately designed retry route. Do not add extra watched fields without revisiting the transition conditions and duplicate tests.

For failed or interrupted execution, inspect both the created activity and the marker before retrying. The guard helps control repeated sequential events; it is not a claim of exactly-once execution under concurrent requests. If concurrent processing or strict uniqueness is material, have a developer design and test an appropriate transactional implementation.

Use a Small Code Model to Review the Gate

A pure Python model can make the intended decision easy to discuss, but it does not execute or validate Odoo. The example below represents the business gate with strings and Booleans; it is not an ORM domain or server-action snippet to paste into Studio.

`def should_create_follow_up(before_stage, after_stage,
assigned, already_created,
creating=False):
enters_stage = creating or before_stage != "Qualified"
return (
enters_stage
and after_stage == "Qualified"
and assigned
and not already_created
)

assert should_create_follow_up("New", "Qualified", True, False)
assert not should_create_follow_up("Qualified", "Qualified", True, False)
assert not should_create_follow_up("New", "Qualified", False, False)
assert not should_create_follow_up("New", "Qualified", True, True)
assert should_create_follow_up(None, "Qualified", True, False, creating=True)`

This code models the positive and negative cases, including the creation exception. The Odoo test matrix must still verify that the selected trigger, fields, conditions, action order, permissions, and assignment produce the same behavior in the database.

For a no-code rule, keep the accepted configuration record alongside these expected outcomes. If the process later requires code, use the same cases as acceptance criteria and add tests for concurrency and failure recovery where relevant.

Troubleshoot Scope Before Adding More Actions

Check the trigger, watched fields, conditions, and action ownership before making the rule more complicated. A missing activity can have a straightforward cause: the record did not undergo the watched event or did not match the post-condition.

If activities repeat, inspect the actual updated fields, the guard value, other active rules, and the route that performed the write. Confirm the activity marker is being set by the intended action and that another automation does not reset it.

If an activity has the wrong owner, review the Dynamic User field path. Odoo’s Create Activity action supports dynamic assignment from a user linked to the record; the correct relation matters.

If a time-based rule behaves differently, stop applying assumptions from this event-driven example. Odoo 20 documents a scheduled checker for timing conditions and a setup step that initializes execution history to avoid retroactive work. Read that sequence before building reminder rules.

Keep diagnosis evidence specific: affected record, user, changed fields, expected matching conditions, activity outcome, and guard outcome. That is more useful than a screenshot of the rule’s name alone.

Automated Actions and AI Agents Have Different Responsibilities

An automation rule defines the event and configured response. An AI action can introduce model-directed interpretation or tool use inside that process. A deterministic CRM follow-up does not need a model to decide that a known stage changed.

Odoo 20 documentation includes AI agents and AI actions, and describes Update with AI as requiring the Odoo AI app. Those capabilities need their own permissions, evaluation, and operating boundaries.

Also distinguish a time-based automation rule from a general scheduled action. Both involve scheduling, but their configuration and execution conditions differ. Choose the mechanism that matches the event and workload instead of treating every background task as the same feature.

For this example, the human defines qualification and ownership. The rule schedules a known internal activity. Keep that boundary intact until a different business requirement justifies changing it.

Promote the Rule With a Recovery Plan

Promote only after the business owner accepts the observed test results and the administrator can reproduce the configuration. Keep the first production scope narrow and inspect its actual outputs.

Record the rule name, model, trigger, watched fields, domains, selected stage, custom field name, ordered actions, and test evidence. Have the operations owner confirm how unassigned opportunities and intentional retries will be handled.

WiserBrand’s business process automation offering covers process mapping, tool integration, and maintenance. For an Odoo project, ask the proposed team to demonstrate the exact trigger, permissions, repeat guard, and recovery procedure in the target version. Define the support scope before handover.

To stop future execution, disable or archive the rule through the controls available in the database. Preserve the configuration for diagnosis. Then identify activities already created and review them before correction. Disabling the rule does not remove them or reverse business actions.

If a guard was set incorrectly, inspect the opportunity and its activity history before resetting it. Blindly clearing markers can make previously processed opportunities eligible again. Do not delete legitimate activities during cleanup simply because their summaries match the test phrase.

Assign a maintenance owner to retest the rule after upgrades, stage changes, field changes, or revisions to related automations. A small rule still has dependencies.

FAQ

What Are Odoo Automated Actions?

Odoo automated actions are configured rules that perform work when a supported event occurs and the record matches defined conditions. In Odoo 20, the documentation calls them automation rules. A rule combines a model, trigger, filters, and actions such as updating a record or scheduling an internal activity.

Do Automated Actions Require Python?

No. Supported actions can be configured through Studio, including record updates and activity creation. Python becomes relevant when the required behavior exceeds those configuration options. Check the version, subscription, hosting, and maintenance implications before adding code. This walkthrough uses predefined actions and includes a separate illustrative model for discussing its gate.

How Can I Reduce Duplicate Activities?

Watch only the fields relevant to the event, distinguish the pre-update and post-update conditions, and add a persistent repeat guard when the business requires once-per-record behavior. Test later edits, stage re-entry, and retries. These measures do not by themselves prove exactly-once behavior under concurrency or every integration route.

Does Disabling a Rule Undo Its Earlier Work?

No. Disabling a rule is a way to stop future execution, not a reversal of completed actions. Review the affected records and outputs before making corrections. Activities may need individual cleanup, while external messages cannot be unsent. Preserve configuration and execution evidence so the owner can determine the right recovery action.

Start With a Transition You Can Verify

Use Odoo automated actions when a clear event, reliable condition, and predefined response match the business need. Begin with an internal action whose result is easy to inspect.

Use the configuration record and test matrix as a starting brief for an implementation discussion with WiserBrand. Build the CRM rule in a copied database and record the observed results. Promote it only when its configuration, owner, exception procedure, and recovery steps are understood by the people who will operate it.

DEV Community: Ethan Mercer