Server Actions in Odoo 19:
Automate Business Logic Without Custom Code

Your Team Is Writing Python Modules for Logic That Odoo Can Handle Out of the Box

We audit Odoo implementations every week. The pattern is always the same: a developer wrote a 200-line Python module to auto-assign sales orders to a team, another module to send a reminder email when an invoice is 7 days overdue, and a third to archive inactive products. Each module has an __manifest__.py, a model file, maybe a cron XML — and each one needs to be maintained, tested, and upgraded across Odoo versions.

Every one of those use cases could have been a Server Action — configured in the UI in 10 minutes, with zero deployment, zero module dependencies, and zero upgrade friction. Server Actions are Odoo's built-in automation engine, and in Odoo 19 they've become powerful enough to replace a significant portion of custom module code.

This guide covers everything you need to build production-grade automations using Server Actions: every action type, the Python execution context, trigger conditions, scheduled actions (cron), chaining actions into sequences, debugging strategies, and the performance traps that catch most teams.

The 6 Server Action Types in Odoo 19 and When to Use Each One

Server Actions live under Settings → Technical → Server Actions (enable Developer Mode first). Each action targets a specific model and performs one of six operations. Understanding which type fits your use case saves you from overcomplicating things with "Execute Python Code" when a simpler action type would work.

Configuring an Update Record Action via XML

While you can configure Server Actions entirely through the UI, defining them in XML data files makes them version-controlled and deployable across environments. Here's a Server Action that marks overdue tasks as high priority:

<odoo>
  <data noupdate="1">

    <!-- Server Action: Set overdue tasks to high priority -->
    <record id="action_task_set_high_priority" model="ir.actions.server">
      <field name="name">Set Overdue Tasks to High Priority</field>
      <field name="model_id" ref="project.model_project_task"/>
      <field name="binding_model_id" ref="project.model_project_task"/>
      <field name="binding_view_types">list</field>
      <field name="state">object_write</field>
      <field name="update_field_id"
             ref="project.field_project_task__priority"/>
      <field name="update_related_model_id"
             ref="project.model_project_task"/>
      <field name="value">1</field>
      <field name="value_type">value</field>
    </record>

  </data>
</odoo>

Key fields explained: state determines the action type — object_write for Update Record, object_create for Create Record, code for Execute Code, email for Send Email, followers for Add Followers, and sms for Send SMS. The binding_model_id adds the action to the "Action" dropdown menu on the model's list/form views, letting users trigger it manually on selected records.

Scheduled Actions (Cron Jobs): Running Server Actions on a Timer in Odoo 19

Scheduled Actions are Server Actions with a clock. They run automatically at intervals you define — every hour, every day, every Monday at 6 AM. Under the hood, a Scheduled Action is an ir.cron record linked to an ir.actions.server record. The cron worker triggers the server action with an empty recordset, so your code must query for the records it needs.

Here's a Scheduled Action that finds invoices overdue by more than 7 days, sends a reminder email, and escalates invoices overdue by 30+ days to the finance manager:

<odoo>
  <data noupdate="1">

    <!-- Server Action: Process overdue invoices -->
    <record id="action_overdue_invoice_reminder"
            model="ir.actions.server">
      <field name="name">Process Overdue Invoice Reminders</field>
      <field name="model_id" ref="account.model_account_move"/>
      <field name="state">code</field>
      <field name="code">
today = datetime.date.today()
week_ago = today - datetime.timedelta(days=7)
month_ago = today - datetime.timedelta(days=30)

# Find posted invoices that are overdue
overdue_invoices = env['account.move'].search([
    ('move_type', '=', 'out_invoice'),
    ('state', '=', 'posted'),
    ('payment_state', 'in', ['not_paid', 'partial']),
    ('invoice_date_due', '&lt;=', str(week_ago)),
])

if not overdue_invoices:
    log("No overdue invoices found")

# Separate into reminder vs escalation buckets
reminder_invoices = overdue_invoices.filtered(
    lambda inv: inv.invoice_date_due >= str(month_ago)
)
escalation_invoices = overdue_invoices.filtered(
    lambda inv: inv.invoice_date_due &lt; str(month_ago)
)

# Send reminder email (7-30 days overdue)
reminder_template = env.ref(
    'account.email_template_edi_invoice',
    raise_if_not_found=False,
)
if reminder_template and reminder_invoices:
    for inv in reminder_invoices:
        reminder_template.send_mail(inv.id, force_send=False)
    log("Sent %d reminder emails" % len(reminder_invoices))

# Escalate to finance manager (30+ days overdue)
finance_manager = env.ref(
    'base.user_admin', raise_if_not_found=False
)
if finance_manager and escalation_invoices:
    for inv in escalation_invoices:
        inv.activity_schedule(
            'mail.mail_activity_data_todo',
            date_deadline=today,
            summary='ESCALATION: Invoice %s overdue %d days'
                % (inv.name,
                   (today - inv.invoice_date_due).days),
            user_id=finance_manager.id,
        )
    log("Escalated %d invoices" % len(escalation_invoices))
      </field>
    </record>

    <!-- Cron: Run every day at 6:00 AM -->
    <record id="cron_overdue_invoice_reminder" model="ir.cron">
      <field name="name">Overdue Invoice Reminder</field>
      <field name="model_id" ref="account.model_account_move"/>
      <field name="state">code</field>
      <field name="code">
        model.env.ref(
            'my_module.action_overdue_invoice_reminder'
        ).run()
      </field>
      <field name="interval_number">1</field>
      <field name="interval_type">days</field>
      <field name="numbercall">-1</field>
      <field name="active">True</field>
    </record>

  </data>
</odoo>

Key details about Scheduled Actions in Odoo 19:

• numbercall = -1 means the cron runs indefinitely. A positive integer means it runs that many times then deactivates itself. Use 1 for one-shot migration scripts.
• interval_type accepts minutes, hours, days, weeks, and months. There is no "seconds" option — if you need sub-minute frequency, you're solving the wrong problem with cron.
• records is empty in Scheduled Actions. The action is not triggered by a specific record, so you must search() for the records you want to process. Forgetting this is the #1 cause of "my cron does nothing."
• Cron runs as OdooBot (user ID 1) by default. If your code checks env.user or uses record rules that filter by user, the results may differ from what you see in the UI.

Chaining Multiple Actions with Server Action Sequences

Sometimes a single action type isn't enough. You need to update a field, then send an email, then create a follow-up task — all triggered by one event. Odoo 19 supports this with action sequences: a Server Action whose type is "Execute several actions" (state='multi'), which runs a list of child actions in order.

<odoo>
  <data noupdate="1">

    <!-- Step 1: Mark lead as won -->
    <record id="action_lead_won_update" model="ir.actions.server">
      <field name="name">Lead Won: Update Fields</field>
      <field name="model_id" ref="crm.model_crm_lead"/>
      <field name="state">object_write</field>
      <field name="update_field_id"
             ref="crm.field_crm_lead__priority"/>
      <field name="value">3</field>
      <field name="value_type">value</field>
    </record>

    <!-- Step 2: Send congratulations email -->
    <record id="action_lead_won_email" model="ir.actions.server">
      <field name="name">Lead Won: Send Email</field>
      <field name="model_id" ref="crm.model_crm_lead"/>
      <field name="state">email</field>
      <field name="template_id"
             ref="crm.mail_template_lead_won"/>
    </record>

    <!-- Step 3: Create onboarding task -->
    <record id="action_lead_won_task" model="ir.actions.server">
      <field name="name">Lead Won: Create Task</field>
      <field name="model_id" ref="crm.model_crm_lead"/>
      <field name="state">object_create</field>
      <field name="crud_model_id" ref="project.model_project_task"/>
      <field name="link_field_id"
             ref="project.field_project_task__sale_order_id"/>
      <field name="fields_lines">
        <field name="col1"
               ref="project.field_project_task__name"/>
        <field name="value">
          Client Onboarding: {{object.partner_id.name}}
        </field>
        <field name="evaluation_type">equation</field>
      </field>
    </record>

    <!-- Sequence: Run all three in order -->
    <record id="action_lead_won_sequence" model="ir.actions.server">
      <field name="name">Lead Won: Full Sequence</field>
      <field name="model_id" ref="crm.model_crm_lead"/>
      <field name="state">multi</field>
      <field name="child_ids" eval="[
          (4, ref('action_lead_won_update')),
          (4, ref('action_lead_won_email')),
          (4, ref('action_lead_won_task')),
      ]"/>
    </record>

  </data>
</odoo>

Sequences run inside a single database transaction. If Step 3 fails, Steps 1 and 2 are rolled back. This is a feature: you don't end up with a "won" lead that has a congratulations email sent but no onboarding task. However, it also means that if any step raises an exception, nothing is saved — including the email, which was queued but not committed.

Combining Sequences with Automation Rules

You can also chain Server Actions with Automation Rules (Settings → Technical → Automation). An Automation Rule triggers a Server Action when a record is created, updated, or matches a timed condition. Here are the trigger types available in Odoo 19:

The combination of Automation Rules + Server Action Sequences covers 90% of the business logic that teams typically build as custom Python modules. The "Based on Timed Condition" trigger is particularly powerful — it replaces the need for most custom cron jobs by letting you express time-based logic declaratively: "7 days after invoice due date, if payment state is still 'not_paid', run this action."

Debugging Server Actions: Logging, Error Handling, and the ir.logging Table

Server Actions fail silently by default. When an Execute Code action raises an exception, Odoo catches it, logs it to the server log, and shows a generic error to the user. No stack trace in the UI, no indication of which line failed. Here's how to build observable, debuggable Server Actions:

# Pattern: Wrap logic in try/except, log everything,
# use Warning (UserError) for user-facing errors

log("Starting batch processing for %d records" % len(records))
processed = 0
errors = []

for rec in records:
    try:
        if not rec.partner_id:
            log("Skipping %s: no partner" % rec.display_name,
                level='warning')
            continue

        # Your business logic here
        old_state = rec.state
        rec.write({{'state': 'confirmed'}})
        log("Updated %s: %s -> confirmed" % (
            rec.display_name, old_state))
        processed += 1

    except Exception as e:
        errors.append("%s: %s" % (rec.display_name, str(e)))
        log("Error processing %s: %s" % (
            rec.display_name, str(e)), level='error')

log("Batch complete: %d processed, %d errors" % (
    processed, len(errors)))

if errors and len(errors) == len(records):
    raise Warning(
        "All records failed to process:\n" +
        "\n".join(errors[:10])
    )

The log() function writes to the ir.logging table, which you can browse at Settings → Technical → Logging. Each entry includes the timestamp, log level, function name, path, and your message. This is your primary debugging tool for Server Actions — far more reliable than print() statements, which only appear in the server stdout and are lost when the worker restarts.

Performance Considerations

Server Actions run inside the same worker process as user requests. A Server Action that takes 30 seconds to execute blocks that worker for the entire duration. On a server with 4 workers, one long-running action means 25% of your capacity is gone. Follow these rules to keep Server Actions fast:

• Never use search() inside a loop. If you need to look up related records, fetch them all at once before the loop with a single search() and build a dictionary for O(1) lookups.
• Prefer write() on a recordset over individual rec.write() calls. Writing to 100 records at once generates one SQL query; writing one at a time generates 100.
• Use sudo() sparingly. It bypasses record rules, which means no security filtering — but also no index hints from the security filters. Queries on large tables without record rules can be dramatically slower.
• Batch large operations. For Scheduled Actions processing thousands of records, use search([], limit=500) with env.cr.commit() between batches. This prevents long transactions, reduces memory usage, and makes the action resumable if it times out.

Here's the batch processing pattern we use in every Scheduled Action that touches more than a few hundred records:

# Batch processing: avoids worker timeout and memory issues
BATCH_SIZE = 500
offset = 0
total_processed = 0

while True:
    # Fetch next batch (search is re-executed each loop
    # because committed records may change filter results)
    batch = env['product.template'].search(
        [('active', '=', True),
         ('write_date', '<=',
          str(datetime.date.today()
              - datetime.timedelta(days=180)))],
        limit=BATCH_SIZE,
        order='id ASC',
    )

    if not batch:
        break

    # Process batch
    batch.write({{'active': False}})
    total_processed += len(batch)

    # Commit between batches — saves progress,
    # releases DB locks, frees memory
    env.cr.commit()

    # Clear ORM cache to prevent memory buildup
    env.invalidate_all()

    log("Archived %d products (total: %d)" % (
        len(batch), total_processed))

log("Batch complete: %d products archived" % total_processed)

4 Server Action Mistakes That Break Production Odoo Instances

Optimization Metadata