What a server action is

A server action is a defined piece of work Odoo can carry out on a record: update a field, create a record, send an email, run a sequence of other actions.

The difference from an automated action is what starts it.

An automated action fires on its own when something happens — a record is created, a field changes.

A server action is a reusable piece of work that can be triggered several ways: from a button, from a menu item, on a schedule, or by an automated action calling it.

Think of an automated action as the trigger and a server action as the thing being done. In practice they overlap, and the useful distinction is reusability.

What they can do without code

Odoo offers several action types, and most everyday needs are covered without writing anything.

Update a record. Set a field on the record you are working with, or on a related one.

Create a record. Make a new record of any type — an activity, a task, a follow-up.

Send an email. Using a template.

Add followers. So the right people are notified of changes.

Send a notification. To a user, in the interface.

Run several actions. Group actions together and run them as one.

Execute Python code. Where the logic is beyond the above. This is developer territory and should live in a module rather than in a configuration screen.

Where they earn their place

Three patterns cover most real use.

1. A button on a form

The most visible use. Add a server action to the Action menu of a record, and users can run it on demand.

Examples: mark an order as reviewed and notify the manager, create a standard set of follow-up activities, apply a set of default values.

Why it helps: it turns a five-click routine into one click, and it makes sure the routine is done the same way every time.

2. Called by an automated action

The automated action decides when. The server action does the work.

Why separate them: if three different conditions should produce the same result, you write the work once and reference it three times. Change it in one place.

3. On a schedule

Attached to a scheduled job that runs nightly, hourly or weekly.

Examples: flag records that have sat too long, produce a daily summary, clean up drafts older than a set period.

Bulk operations

A use worth knowing about because it saves real time.

A server action added to a list view can run on many records at once. Select fifty records, run the action, and it applies to all of them.

Examples: set a field across a batch, add a tag, create an activity for each.

Test it on two records first. A bulk action applied to eight hundred records with wrong logic is a bad afternoon, and undoing it may not be possible.

The limits

Four, and knowing them saves you from building something that becomes a problem.

Complex logic. If describing the rule takes a paragraph with several exceptions, it belongs in a module where it can be reviewed and tested.

No test-then-release. A server action applies to your live system as soon as it is saved. There is no staging step unless you deliberately build the action in a separate database and recreate it.

No history of why. Like Studio changes, these are configured by clicking. Nothing records who created it or what problem it solved.

Python code in a configuration field. Odoo allows it. It is a poor place for real logic — no version control, no code review, no way to see it changed. If you need Python, put it in a module.

The mess that accumulates

The same pattern as automated actions, and it is worth naming.

A company adds a few server actions. Sensible ones. Two years later there are thirty, created by different people, and nobody remembers what half of them do.

Then something behaves oddly and somebody has to work out which of thirty actions is responsible.

Three safeguards:

Name them properly. Not “Server Action 4”. Something that says what it does — “Notify manager: order over 50k”.

Keep a written log. What, when, why, who asked for it. A shared document is enough.

Review every six months. Deactivate what is no longer used. Actions outlive the situations that created them.

Testing safely

Two habits that prevent most accidents.

Test in a staging database first — a neutralised copy of production, so test emails do not reach real customers and scheduled jobs do not fire against live systems.

Start narrow. Run it on one or two records. Check the result. Then widen.

The temptation is to run it across everything immediately. The cost of that going wrong is much higher than the ten minutes of patience.

Before you build one

Four questions.

Does a setting already do this? Odoo has follow-up levels, activity scheduling and reordering rules built in. Check first.

What happens if it runs wrongly? An email to the wrong person is embarrassing. A field updated across thousands of records is worse. Consider the blast radius before, not after.

How will we know it stopped working? Scheduled actions fail quietly.

Who owns it? Somebody should be able to explain it in a year.

When to use a module instead

Move to code when:

• The logic needs more than a couple of conditions
• It runs at high volume
• You need it tested before it reaches production
• You need a record of what changed and why
• It has to talk to another system
• You would be uncomfortable explaining it to an auditor from memory

That last one is a good test. If the rule matters enough to defend, it should live where it is documented and reviewable.

The short version

Server actions are the reusable work in Odoo’s automation — run from a button, a schedule, or by an automated action.

They are genuinely useful for routine operations, and they cover more than people expect without any code.

The risk is accumulation. Thirty undocumented actions that nobody can untangle.

Name them well, write down why, test narrow, and review twice a year. That is the whole discipline.