A useful Odoo support request makes the problem reproducible and its business impact clear. “Odoo is broken” leaves a technician guessing. “Three warehouse users cannot validate deliveries after this morning’s add-on update; existing orders are readable and no safe dispatch workaround is available” gives the investigation a starting point.
This guide covers incident reporting and controlled recovery. The platform references were checked on 10 November 2026 against Odoo 19 documentation. Available tools and responsibilities depend on your hosting, permissions and support agreement.
1. Route the issue to the right owner
Identify whether the affected workflow uses a standard application, a custom add-on, an external connector or infrastructure managed by your organisation. Record your Odoo version and whether the database uses Odoo Online, Odoo.sh or another host.
Odoo’s Enterprise agreement distinguishes standard-feature support and covered extra modules from other development or customisation assistance. It also describes working through Odoo or an Odoo partner. Check your actual agreement and named support contact rather than assuming every extension has the same coverage.
A practical responsibility list names the vendor contact, implementation partner, custom-module maintainer, hosting administrator and business process owner. Keep one coordinator accountable for the incident even when several suppliers investigate. An acknowledgement, workaround and permanent correction are different milestones; agree the next update without inventing a resolution deadline.
2. Collect a small, useful evidence pack
The official support form asks for a topic, application, summary and detailed description, with options for supporting evidence. Prepare those details before opening the ticket so the first exchange moves the investigation forward.
| Information | Useful content | Avoid |
|---|---|---|
| Observed failure | Exact action, expected result and actual result | A conclusion such as “database corruption” without evidence |
| Timing | First occurrence, latest occurrence and timezone | “This morning” without a date |
| Scope | Affected roles, workflows and approximate transaction count | Assuming every user is affected |
| Recent change | Deployment, configuration change or import reference | Changing more settings before recording the baseline |
| Evidence | Redacted error text, minimal screenshot and permitted record reference | Passwords, API keys, session cookies or unnecessary customer records |
Prefer a minimal example with fictional data when it reproduces the issue. Share sensitive evidence only through the agreed support channel with appropriate access. Do not paste a full database export into a general email thread or public forum. If access is needed, use an approved named account with suitable permissions rather than sharing someone’s password.
3. Prioritise by impact and available workarounds
Explain what the business cannot do, how many people or transactions are affected, and whether work can continue safely. A blocked delivery process can warrant faster attention than a cosmetic report issue, but the actual priority should follow your agreed support process.
Record any workaround and its limits. Manual order capture may preserve an enquiry while creating later reconciliation work; disabling a control may introduce unacceptable errors. The business owner should approve operational workarounds and identify who reconciles the backlog.
4. Reproduce in a suitable test environment
On Odoo.sh, staging builds use a copy of production data, while development builds use new databases and demo data. The Odoo.sh build documentation also describes access to logs and revision information. Include the relevant build or change reference when an issue follows a deployment.
For Odoo Online, the database-management guide describes creating a duplicate for testing. A staging environment is not automatically a privacy-free environment: production copies can contain real customer information, so retain the required access controls.
Odoo’s neutralised-database guidance lists disabled external actions such as outgoing email and payment providers. Confirm the test environment’s state before reproducing an incident, including any custom integration. Avoid accidentally creating real orders, messages or charges while investigating.
5. Test the correction and plan recovery
Fictional example: a distributor reports that delivery validation fails after a custom carrier module update. The coordinator records the error and update reference, then the authorised maintainer reproduces it in staging. The team tests a correction against the failing delivery, an ordinary delivery and a cancellation before deciding whether to release it.
The scenario does not establish that a custom module caused every similar error. It illustrates the evidence needed to separate correlation from a confirmed cause. Keep the original reproduction steps so the business owner can repeat the test.
Before a production change, identify the release owner, backup position, rollback decision-maker and expected interruption. A code rollback and a database restore have different consequences. Restoring an older database can remove later transactions, so any recovery plan must address the intervening business activity.
6. Close with evidence
Confirm the affected workflow works for the original user role, review delayed transactions and record any remaining limitation. Close the ticket with the cause established, change applied, validation result and follow-up owner. A successful deployment alone does not prove the operational problem is resolved.
For help defining responsibilities, explore Lava’s Odoo services or send an enquiry with your version, hosting arrangement and a non-sensitive description of the affected workflow.