The Approval Gate Is in the Code: How to Make an Odoo 19 AI Server Action Wait for a Person

In Odoo 19, an AI server action never asks for confirmation: Odoo’s documentation says a called tool “will execute unconditionally, unless the code itself prevents it”. So the approval gate has to be built into the tool. We build tools that create drafts, log a note and assign an activity to a named person, and never post, send or hold, like all our AI agents for ERP in Australia.

At a glance

• Who it is for: Australian businesses on Odoo 19 Enterprise whose finance or operations team wants an AI server action to triage records overnight (disputed invoices, inbound documents, service tickets) without anything posting, sending or changing status until a person has looked.
• Problem it solves: the AI action decides which tool to call and the tool runs without a confirmation step. If the tool posts an invoice, it is posted. The gate you assumed the model would add does not exist, so it has to be designed in.
• Platforms: Odoo 19 Enterprise with the AI app. Odoo Online uses Odoo’s own model connection; Odoo.sh and on-premise databases need your own OpenAI or Google Gemini API key. Not available in Odoo Community.
• Trigger: an automation rule (on save, on a field change, on an incoming message, or timed), a scheduled action, or a person picking the action from the Actions menu on a record.
• Inputs read: the record the rule fired on, the fields you name in the prompt, attachments on the record, and whatever the tools you assign are allowed to look up. It reads nothing you did not put in the prompt or a tool.
• What the agent drafts: an internal note summarising what it found and why, a draft document (a credit note, a bill, a task) left in draft state, and an activity assigned to a named person with a due date.
• Approval gate: the person clears the activity by posting, sending or rejecting the draft themselves. No tool assigned to the action can post, send, confirm or change credit status.
• Audit trail: Odoo logs every AI action run as an internal note in the record’s chatter under the AI agent’s name, listing each tool called and the arguments it passed. We add the run to the agent register alongside it.
• Typical cycle time: minutes from trigger to drafts waiting; the person’s review is the real elapsed time and depends on your queue, so we leave the figure out until a pilot measures it.
• What it never does: post a journal entry, credit note or invoice; confirm a sales or purchase order; send an email or SMS to a customer; place or lift a credit hold; change a price, tax code or payment term; delete anything.
• Typical cost: a single scoped agent pilot typically starts from a few thousand dollars ex GST for discovery and sandbox build, per our AI agents for ERP in Australia page.
• Typical timeline: 4 to 10 weeks from discovery to a drafts-first go-live, per the same page.
• Last verified: 21 September 2026 against Odoo’s 19.0 AI server actions documentation, the 19.0 AI overview and the 19.0 Enterprise source code, which every Enterprise subscriber can read.

Most AI-in-ERP content promises the model will “know” not to do anything rash. We read the code instead. This post is the build note we hand to clients who want to switch on AI server actions in Odoo 19 and keep a person between the model and the ledger.

What is an Odoo 19 AI server action, and why doesn’t it ask permission?

An AI server action is a normal Odoo server action whose type is AI. It has a prompt, a model it runs on, and a list of tools. A tool is any other server action on the same model with the Use in AI box ticked on its Usage tab. Odoo’s documentation describes the split as manager and worker: the AI action reads the record, interprets the prompt and picks a tool with arguments; the tool does the work. The manager enforces no business rules, changes no records itself and gives no guarantee that the result is correct; its whole job is the decision.

The source makes the point sharper. The system prompt Odoo sends with every AI action tells the model that its job is to execute actions on the record, that it must not ask for confirmation, and that it must not request input from a user, because it is not talking to one. That is the right design for an automation that runs from an overnight cron. It also means the only place a “wait for a person” step can live is inside the tool.

Three more details from the 19.0 source that matter when you design the gate:

• Only some action types can be tools. Execute Code, Create Record, Duplicate Record, Create Next Activity, Add or Remove Followers, Send Webhook, Send Email (which can also post a message or an internal note), and an Update Record that writes a fixed value or a sequence. An Update Record tool cannot write a value the model chose. If you want the model to supply a value, the tool has to be Execute Code with that argument declared in the AI Schema, exactly as the documentation describes for the folder-sorting example.
• The tool runs until the model says it is done. Each tool can carry an end-of-run flag; the loop continues until the model sets it. Plan for the model calling more than one tool in a run, and make every tool safe to call on its own.
• The provider and model for AI actions are set in code. In the 19.0 source we read on 21 September 2026, the AI action is pinned to OpenAI and a specific model name, while the chat agents let you choose from a list of OpenAI and Google models. Odoo warns that models are retired; treat the name in the code as something that will change under you.

None of this is a criticism. It is a clear contract. The model chooses, the tool acts, and the tool is Python that you wrote, which is exactly where we want the risk to sit.

Where does the approval gate go?

Three patterns cover almost every case we have built. Each one works because the tool is only allowed to do something that a person has to finish.

What all three have in common: the write the tool performs is reversible and invisible to the customer. A draft can be deleted. An activity can be dismissed. A stage can be moved back. A posted invoice with the wrong GST code, or a reminder email to a customer who paid last week, cannot be unsent.

A worked example: the disputed invoice

Here is the pattern we build for accounts receivable teams, and it pairs with the AI credit management agent we described separately.

A customer replies to a payment reminder saying the invoice is wrong because two cartons arrived damaged. In Odoo 19 that reply lands in the invoice’s chatter. An automation rule on incoming messages fires the AI action, whose prompt says: read the message and the invoice, decide whether this is a dispute, a promise to pay or a query, and use the tools accordingly.

The action has three tools and no others. Log Dispute Summary is an Execute Code tool that posts an internal note (not an email) with the customer’s claim, the invoice lines it affects and the amount in question. Assign to AR Officer is a Create Next Activity tool with a two-day due date. Draft Credit Note is an Execute Code tool that creates a credit note in draft against the invoice for the disputed lines, with the GST on those lines carried through, and stops there.

By 7am the AR officer has an activity, a note that reads like a colleague’s handover, and a draft credit note to check against the delivery docket. She confirms the damage claim with the warehouse, adjusts the quantity to the two cartons the docket supports, not the three the customer claimed, and posts the credit note herself. The posted credit note is the adjustment note the ATO generally requires before a decreasing adjustment above $75 of GST can go on a Business Activity Statement (BAS), per the ATO’s adjustment notes page, and a person issued it. The customer gets the credit note and a reply written by the officer, not the model.

“The model is good at reading the email and finding the lines. It is not the one who should decide whether the customer gets a credit. So we let it draft everything and post nothing, and the officer’s morning starts with a decision instead of an inbox.”

Bill Alvarez, Practice Manager, Auboros

Nothing in that flow is fragile. If the model misreads the message and drafts a credit note for the wrong lines, the officer deletes a draft. If it calls the wrong tool, the chatter shows which one.

Whose permissions does the tool run with?

This is the question every CFO asks, and the source answers it in two halves.

First, the tool code runs without superuser rights. The record, the model and the environment are handed to the tool with superuser switched off, so Odoo’s normal access rules and record rules apply to whatever the tool reads or writes. That is the good half.

Second, the access check is done once, on the AI action, and then skipped on the tools. Odoo checks that the user in whose name the run happens is allowed to execute the AI action, then runs its tools without checking their own group restrictions. The AI action form shows a warning icon when a tool carries a group, with a tooltip warning that the groups set on the tools will not limit the AI. So the question becomes: which user is the run happening as? For a rule that fires on save, it is the person who saved the record. For a timed rule or a scheduled action, it is the user configured on that job, and if that is an administrator, your tools run with an administrator’s reach. We set scheduled AI actions to run as a dedicated internal user with the narrowest groups that let the tools do their job, the same role-scoped permissions approach we use for external agents.

Two behaviours to design around. When a tool fails, including on an access error, Odoo does not stop the run: the error text is returned to the model as the tool’s result, and the model may try something else. Write the prompt so that a failed tool means stop and hand over, and write tools that fail loudly instead of half-completing. And a tool that tries to open a screen or wizard is refused with an error saying the action is interactive and cannot be run by the agent, which is a useful guarantee: the model cannot click through a confirmation dialog on your behalf.

One cost line for the budget: an external agent connecting through Odoo’s API needs its own internal user on the Custom plan, the plan that includes the external API on Odoo’s pricing. An AI server action running inside the database does not need an extra seat, though the dedicated user we recommend for scheduled runs does.

What does the audit trail look like?

Odoo writes it for you, in the place your team already looks. After each run on a record that has a chatter, the AI action logs an internal note in the record’s chatter under the AI agent’s own name: the action that ran, the tools it called, and the arguments it passed to each. If a run drafted a credit note for lines 2 and 3, the note says so, on the invoice, timestamped, next to the customer’s email that started it. The server log carries the same calls with timings.

We add two things of our own. The agent, its prompt, its tools, its trigger, its run-as user and its owner go into the AI agent register, so the question “what can this thing do” has a one-page answer. And where the record is about an identifiable person, a sole trader customer say, the register notes it, because from 10 December 2026 privacy policies must describe the kinds of substantially automated decisions that significantly affect people. A triage that only drafts and hands over is the easy case to describe; a tool that posted the credit on its own would not be.

What should an Odoo AI tool never be allowed to do?

Because the tool runs the moment the model calls it, the list of things it is never given is more important than the prompt. Ours, for finance and operations actions:

• Post anything to the ledger. No tool calls the posting method on an invoice, bill, credit note or journal entry. Drafts only.
• Confirm an order. Sales and purchase confirmations trigger stock moves and commitments to customers and suppliers. A person clicks Confirm.
• Send to a customer or supplier. The Send Email action type is a valid tool, and in its email mode it sends. We use it only in internal-note mode, or not at all.
• Touch credit, price or tax. Credit holds, credit limits, price lists, tax codes and payment terms stay as buttons for people. The credit management post covers why a wrong hold costs more than a late one.
• Delete or archive. Nothing the model can call removes a record. Archive is a person’s decision, and delete usually shouldn’t happen at all.

The read-only Ask AI agent that ships with Odoo 19 is a different animal: Odoo’s documentation says the standard agent cannot make changes to the database, which is why we cover it separately in our guide to AI agents in Odoo. AI server actions are where writes happen, and so they are where the design work is. What Odoo 20 changes here is unknown until it is unveiled at Odoo Experience on 24 to 26 September 2026; we track confirmed against expected in our Odoo 20 roadmap breakdown, and nothing above stops being true when a newer version arrives.

Goes well with

• How to scope an agent’s permissions and approval gates, for the question of who the run-as user should be.
• What else Odoo 19’s AI can and can’t do, for the read-only agent, Topics and Sources side.
• The AI credit management agent, for the accounts receivable process the worked example sits inside.

---

Want an Odoo 19 AI server action that drafts and waits?

We build and govern AI server actions for Odoo 19 businesses from Brisbane, with the approval gate written into the tool and the run logged where your team already works. As an Odoo partner in Brisbane with an accounting background, we can tell you which of your processes should get a draft-only tool first. If you want one scoped for your database, book a free consultation. We’ll read your automation rules before we suggest anything.