A server action<\/strong> 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.<\/p>\n The difference from an automated action is what starts it<\/strong>.<\/p>\n An automated action<\/strong> fires on its own when something happens \u2014 a record is created, a field changes.<\/p>\n A server action<\/strong> 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.<\/p>\n 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.<\/p>\n FIGURE 1: TRIGGER OR ACTION?<\/p>\n Automated action<\/p>\n Server action<\/p>\n Odoo offers several action types, and most everyday needs are covered without writing anything.<\/p>\n Update a record.<\/strong> Set a field on the record you are working with, or on a related one.<\/p>\n Create a record.<\/strong> Make a new record of any type \u2014 an activity, a task, a follow-up.<\/p>\n Send an email.<\/strong> Using a template.<\/p>\n Add followers.<\/strong> So the right people are notified of changes.<\/p>\n Send a notification.<\/strong> To a user, in the interface.<\/p>\n Run several actions.<\/strong> Group actions together and run them as one.<\/p>\n Execute Python code.<\/strong> Where the logic is beyond the above. This is developer territory and should live in a module rather than in a configuration screen.<\/p>\n Three patterns cover most real use.<\/p>\n The most visible use. Add a server action to the Action menu of a record, and users can run it on demand.<\/p>\n Examples:<\/strong> mark an order as reviewed and notify the manager, create a standard set of follow-up activities, apply a set of default values.<\/p>\n Why it helps:<\/strong> it turns a five-click routine into one click, and it makes sure the routine is done the same way every time.<\/p>\n The automated action decides when. The server action does the work.<\/p>\n Why separate them:<\/strong> if three different conditions should produce the same result, you write the work once and reference it three times. Change it in one place.<\/p>\n Attached to a scheduled job that runs nightly, hourly or weekly.<\/p>\n Examples:<\/strong> flag records that have sat too long, produce a daily summary, clean up drafts older than a set period.<\/p>\n FIGURE 2: THREE WAYS TO USE ONE<\/p>\n On a button<\/p>\n From an automated action<\/p>\n On a schedule<\/p>\n A use worth knowing about because it saves real time.<\/p>\n A server action added to a list view<\/strong> can run on many records at once. Select fifty records, run the action, and it applies to all of them.<\/p>\n Examples:<\/strong> set a field across a batch, add a tag, create an activity for each.<\/p>\n Test it on two records first.<\/strong> A bulk action applied to eight hundred records with wrong logic is a bad afternoon, and undoing it may not be possible.<\/p>\n Four, and knowing them saves you from building something that becomes a problem.<\/p>\n Complex logic.<\/strong> If describing the rule takes a paragraph with several exceptions, it belongs in a module where it can be reviewed and tested.<\/p>\n No test-then-release.<\/strong> 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.<\/p>\n No history of why.<\/strong> Like Studio changes, these are configured by clicking. Nothing records who created it or what problem it solved.<\/p>\n Python code in a configuration field.<\/strong> Odoo allows it. It is a poor place for real logic \u2014 no version control, no code review, no way to see it changed. If you need Python, put it in a module.<\/p>\n The same pattern as automated actions, and it is worth naming.<\/p>\n 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.<\/p>\n Then something behaves oddly and somebody has to work out which of thirty actions is responsible.<\/p>\n Three safeguards:<\/strong><\/p>\n Name them properly.<\/strong> Not “Server Action 4”. Something that says what it does \u2014 “Notify manager: order over 50k”.<\/p>\n Keep a written log.<\/strong> What, when, why, who asked for it. A shared document is enough.<\/p>\n Review every six months.<\/strong> Deactivate what is no longer used. Actions outlive the situations that created them.<\/p>\n FIGURE 3: MANAGEABLE AND UNMANAGEABLE<\/p>\n Well managed<\/p>\n Accumulated<\/p>\n Two habits that prevent most accidents.<\/p>\n Test in a staging database first<\/strong> \u2014 a neutralised copy of production, so test emails do not reach real customers and scheduled jobs do not fire against live systems.<\/p>\n Start narrow.<\/strong> Run it on one or two records. Check the result. Then widen.<\/p>\n The temptation is to run it across everything immediately. The cost of that going wrong is much higher than the ten minutes of patience.<\/p>\n Four questions.<\/p>\n Does a setting already do this?<\/strong> Odoo has follow-up levels, activity scheduling and reordering rules built in. Check first.<\/p>\n What happens if it runs wrongly?<\/strong> An email to the wrong person is embarrassing. A field updated across thousands of records is worse. Consider the blast radius before, not after.<\/p>\n How will we know it stopped working?<\/strong> Scheduled actions fail quietly.<\/p>\n Who owns it?<\/strong> Somebody should be able to explain it in a year.<\/p>\n Move to code when:<\/p>\n That last one is a good test.<\/strong> If the rule matters enough to defend, it should live where it is documented and reviewable.<\/p>\n Server actions are the reusable work<\/strong> in Odoo’s automation \u2014 run from a button, a schedule, or by an automated action.<\/p>\n They are genuinely useful for routine operations, and they cover more than people expect without any code.<\/p>\n The risk is accumulation.<\/strong> Thirty undocumented actions that nobody can untangle.<\/p>\n Name them well, write down why, test narrow, and review twice a year. That is the whole discipline.<\/p>\n Routine tasks eating your team’s time?<\/p>\n Get in touch. We will look at what can be turned into a one-click action and what genuinely needs a module \u2014 and document both.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9077,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9076","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\n\n
\n
What they can do without code<\/h2>\n
Where they earn their place<\/h2>\n
1. A button on a form<\/h3>\n
2. Called by an automated action<\/h3>\n
3. On a schedule<\/h3>\n
\n
\n
\n
Bulk operations<\/h2>\n
The limits<\/h2>\n
The mess that accumulates<\/h2>\n
\n
\n
Testing safely<\/h2>\n
Before you build one<\/h2>\n
When to use a module instead<\/h2>\n
\n
The short version<\/h2>\n