Odoo 19 to 20 AI: what must you reaccept?

10 min read · 5 Nov 2026
Last reviewed November 5, 2026

Your upgraded database opens. The agent answers a familiar question. The team wants its old automation switched back on. You still need evidence that the workflow uses the intended configuration, reaches the right records and stops where a person must decide.

Before resuming an Odoo 19 AI workflow on 20, map the old configuration to the actual target, confirm its request and billing route, and replay agreed business cases through an approved test setup. Record disabled paths as missing evidence. A named process owner should accept the target behavior before the workflow resumes.

Research checked: 5 November 2026. This is a proposed acceptance method based on versioned official documentation. We have not run an Odoo 19-to-20 migration or measured an agent’s performance. The example and downloadable register are deliberately unexecuted.

Which documented changes require a fresh decision?

Start with differences in documented configuration, then inspect what exists in your upgraded database. The guides identify settings that deserve attention; they do not establish how your particular agents, credentials or custom actions will migrate. A version comparison gives you questions to answer, while the target environment supplies the evidence.

The 19.0 agent guide describes Topics. The 20.0 guide describes Skills, and the response-style choices differ. Map these settings explicitly. Neither a familiar name nor a new label proves that the resulting workflow meets your old acceptance criteria.

The 20.0 AI overview says AI requests consume IAP credits. The 20.0 API-key page is under construction. That gap leaves the fate of a specific old credential arrangement unproven; get a current answer for the exact route you intend to operate.

Turn a documentation difference into a workflow acceptance question
Area to inspect	Question for your target database	Evidence to retain
Agent configuration	Which instructions, tools and response settings are assigned now?	Source and target configuration references, with every intentional difference explained.
Request route	Which service and account handle this workflow’s requests?	Current configuration, account ownership and confirmation of the supported arrangement.
Usage control	Who can see consumption and stop this workflow?	Budget owner, observed monitoring route and tested stop procedure.
Execution	Does the expected trigger reach the intended action under the intended identity?	An execution record for that path, not only an agent configuration screenshot.

The detailed Odoo AI credit budget and AI processing-location evidence belong in their own reviews. Reference those decisions here so the release record stays focused.

What belongs in the before-and-after record?

Capture enough configuration to explain one workflow from trigger to accepted result. Include the exact source and target versions, agent instructions, available tools, source material, execution identity and review boundary. Record both intentional changes and unexplained differences. A list of installed apps is too broad to establish that this particular workflow survived.

Give the workflow a stable identifier, such as STOCK-NOTE-01, and identify its business owner. Record the actual build or deployment reference behind the convenient labels “19” and “20”. If the source environment changes after capture, update the baseline before comparing it with the target.

Keep secrets out of the register. Use a credential reference, account owner and verification date. For each prompt or instruction set, retain an approved snapshot or version reference. For each source, record the document or dataset version used in the acceptance exercise. This makes an observed difference explainable without copying production data into a planning spreadsheet.

A useful change entry states the old setting, the target setting, the reason, the expected effect and who approved it. “Changed to the new default” leaves the business effect unanswered. “Changed wording style; record access and review requirements remain subject to cases R06-A through R06-C” creates something a reviewer can assess.

Keep database reconciliation separate. The migration acceptance and reconciliation guide covers whether business records and balances carried over. This record explains whether the AI-assisted behavior around those records is acceptable.

What does a neutralized test database leave unproven?

A test environment can suppress the path you need to evaluate. Record which triggers, request routes and side effects are disabled before interpreting a result. If a scheduled run never executed or its AI request route was unavailable, mark that part as untested and plan a controlled exercise that supplies the missing evidence.

Odoo’s neutralized-database documentation includes planned actions and IAP tokens among disabled features. The list is non-exhaustive. Our inference is narrow: a successful manual conversation cannot establish that a disabled scheduled or IAP path ran.

Before an exercise, write down its isolation contract: synthetic or approved test data, allowed destinations, account references, spending limit, permitted writes and the person who can stop it. Have the technical owner identify which controls must remain disabled and which specific test route can be enabled or replaced safely. Do not treat neutralization as proof that every custom integration is isolated.

Separate two kinds of evidence. A simulated provider failure can establish that your own handoff code responds to that simulated failure. It does not prove that a real provider account, billing route or request succeeds. Conversely, one successful request says little about the scheduler, repeated delivery or the human review step. Record the boundary of each observation.

If you cannot provide a controlled route before the upgrade window, retain the missing-evidence status and keep the affected automation paused. You can accept other independently tested workflows without pretending this one passed.

How should you replay an existing workflow?

Define expected business behavior before comparing the two environments. Reuse a stable set of approved inputs, then judge each result against the same record, authority and review requirements. Treat the old output as an observation, not the answer key. If the old workflow was wrong, reproducing it would preserve the defect.

Consider a fictional planning team whose assistant prepares an internal stock-exception note. The proposed contract is small: identify the approved source snapshot, describe the exceptions supported by it, keep missing quantities explicit and submit the note for planner review. The assistant must not change stock quantities or send a message outside the review process.

Use a clear exception, an incomplete source and a source containing an instruction to bypass review as three distinct cases. For each, specify the expected result before running either version. A fluent note that invents a missing quantity fails. A differently worded note can pass if its claims, source references and review state satisfy the contract.

Also exercise the route that fails or stops. Decide who receives the work when a request cannot complete, what the user sees and how the team avoids treating “no answer” as “no exceptions”. Record those expectations independently of whatever error wording the product returns.

For detailed write assertions, use the business-state testing guide. The release record should reference those results. It does not need to reproduce every test definition or become a second database reconciliation report.

What evidence goes into the release register?

Keep configuration observations, executed cases and owner approval distinct. Each required row needs a source reference, target reference, expected result, actual observation and reviewer. A row with no actual evidence remains open, even if the surrounding documentation looks complete. The register makes that distinction visible without pretending to automate the acceptance decision.

Download the eight-row workflow evidence register and its usage notes. Every row starts at NOT_RUN, with actual observations and approval fields empty. These are proposed checks, not results from an Odoo installation.

Eight evidence areas for one workflow release
Row	Evidence area	Question it should resolve
R01	Scope and baseline	Which workflow, environments, dataset and owner does this decision cover?
R02	Configuration mapping	Are source-to-target differences understood and approved?
R03	Execution authority	Which trigger, identity and tools can act, and where does review intervene?
R04	Request route	Are account, billing and processing-location decisions current for this route?
R05	Test isolation	Which paths ran, which were simulated and which remained disabled?
R06	Business cases	Do observed results satisfy independently defined expectations?
R07	Failure and handoff	Can the workflow stop with a clear owner for unfinished work?
R08	Release decision	Who accepts the bounded behavior, and what change requires review again?

Use PASS only after the row’s evidence is reviewed, FAIL for an observed contradiction, BLOCKED when the exercise cannot proceed and NOT_RUN before it has happened. For an inapplicable row, record N/A with a reason and reviewer. These are proposed team conventions, not Odoo status fields.

Do not fill evidence cells with “same as before”. Reference the actual configuration snapshot, case result or decision. If an issue is corrected, retain the failed observation and link the recheck rather than overwriting the history with a green cell.

When can the workflow resume?

Resume the bounded workflow when its required observations support the agreed business contract and the named owner accepts the remaining limitations. Missing evidence and observed defects need different treatment, but neither is a pass. If only a manual subset is accepted, make that narrower operating mode explicit and keep the unaccepted trigger disabled.

Proposed decisions after reviewing the evidence
Observed position	Decision	Operating consequence
Required cases pass; route and ownership are confirmed.	Accept the defined scope.	Resume the documented workflow with its monitoring and stop procedure.
Manual path is accepted; scheduled path was not exercised.	Accept only the manual scope, if useful.	Keep scheduling disabled and assign the missing test.
Output looks correct, but account or processing route is unresolved.	Hold the affected route.	Resolve the evidence gap before sending approved business data through it.
A required business condition fails.	Reject that behavior.	Correct it, rerun affected cases and obtain a new decision.

A technical reviewer can establish what ran and what changed. A process owner decides whether the documented result is suitable for the work. Both decisions should name the version, route and workflow scope they cover. An approval for a manual draft does not authorize an unattended write path added later.

Agree what happens if the first production observations contradict acceptance. A pause and a manual fallback may be appropriate; a database rollback needs its own tested plan. Do not assume that disabling an agent reverses records already changed. Keep the release decision separate from any promise that previous data state can be restored.

What should you do before booking the upgrade window?

Identify the AI workflows people depend on, assign an acceptance owner to each and resolve the test-route plan before scheduling their return to service. The first deliverable is a bounded register with honest gaps. That gives the upgrade team something concrete to estimate, test and review instead of a general instruction to “check the AI”.

Start with one workflow whose business result is easy to inspect. Complete its source snapshot, target mapping and case expectations. Then assess whether other workflows share the same configuration and execution route or need separate evidence. Shared infrastructure can reduce repeated work; different authority or side effects still need a distinct decision.

Wavect’s software quality assurance service can help define the acceptance scope and evidence owners. The pre-launch QA checklist provides broader release context. Our Twinsoft AI case study is separate AI delivery context, not evidence that this proposed Odoo upgrade exercise has been run.

Bring the workflow inventory and unresolved release questions. A useful review should end with named tests, known limitations and a person responsible for each decision to resume.

FAQ

Is the old model answer the ground truth?

No. It is evidence of what the old workflow produced. Define expected business facts, authority limits and review requirements independently. If the old answer included an invented quantity or an unauthorized action, reproducing it on the target is still a failure. Keep both observations so reviewers can distinguish an improvement from a regression.

Must every screenshot or response match?

Usually the business requirements matter more than identical wording or layout. Name the fields, source references, states and approval boundaries that must remain correct. If exact formatting is a contractual or downstream integration requirement, add it explicitly. Otherwise, a different response style should not obscure whether the underlying task was completed correctly.

What if our Odoo 19 setup uses a private provider key?

Record the current arrangement without placing the secret in the register. Confirm the supported target configuration, account owner, request route and billing evidence for the exact workflow. The incomplete 20.0 API-key documentation does not prove that an old setup is preserved or prohibited. Keep the affected route unresolved until current evidence answers that question.

Can we skip a dormant workflow?

You can decide to retire it, but record that decision and disable its possible entry points. A forgotten schedule, button or integration can otherwise reactivate work nobody accepted. If the workflow may return later, keep it outside the approved release scope and require fresh evidence before enabling it.

Does a manual button test cover a schedule?

It covers the path you exercised. A schedule may involve different timing, identity, record selection or repeat behavior. Record which components are shared and which remain untested. A disabled schedule needs its own controlled exercise or an explicit decision to keep the workflow manual; a successful button click cannot fill that evidence gap.

How long should the acceptance evidence remain valid?

Tie approval to the recorded configuration and scope instead of choosing an arbitrary permanent expiry. Changes to the request route, instructions, tools, data sources, permissions or trigger should prompt an impact review. Reuse evidence where it still applies, rerun affected cases and record the revised decision. Acceptance is specific to the behavior that was reviewed.