Every Odoo project hits the same question about two weeks in. Can it work the way we already do things, or do we change how we work to suit it?

The honest answer is that Odoo bends a long way before anyone needs to write code. Knowing exactly where that line sits will save you a lot of money, and a fair bit of arguing.

There are four levels to this, and most of the confusion comes from treating them as one thing. They cost different amounts, carry different risk, and behave very differently when you upgrade.

The four levels of Odoo customisation: configuration, Odoo Studio, custom modules, integrations

What can Odoo Studio actually do without code?

Studio is the drag-and-drop tool. You can add fields to existing screens, move things around on forms and lists, build small new models, set up simple automations, tidy up printed documents, and add menu items. For a good chunk of "can Odoo do this" questions, the answer is yes, and nobody needs to open an editor.

Here's the bit that catches people out. Studio only comes with Odoo Enterprise. It isn't in Community. Teams pick Community to keep costs down, assume they'll customise visually later, and find out at the worst possible moment. You can still do plenty on Community through configuration and developer mode, and anything Studio would have done can be written as a module instead, but the visual editor simply isn't there.

Studio's real limit isn't what it can draw. It's what it can decide. The moment a change depends on conditions across several models, or on data sitting outside Odoo, you've left Studio behind.

When do you need a custom Odoo module?

A module is proper software. Python and XML, in version control, installed into a database. You want one when the requirement is about logic rather than layout.

In practice it's usually one of these:

  • Rules with real conditions. Pricing that depends on customer group, volume and contract date all at once. Approval routing that changes with value and department.
  • Computed values that have to stay correct across thousands of records and recalculate properly when their inputs move.
  • Data you have that Odoo doesn't model. Compliance fields, certification expiry, container tracking, batch genealogy.
  • Anything touching another system. An API, a bank feed, a carrier, a storefront.
  • Performance. Reports over large datasets that need SQL rather than looping in Python.

A rough test we use: if you can't explain the change to a new starter in one sentence, it belongs in a module.

What matters more than the code is the discipline. A custom module extends Odoo through inheritance and the documented APIs. It does not edit core files. That one distinction decides whether your customisation still works after an upgrade, which we'll get to shortly.

How do custom Odoo reports and dashboards work?

Reporting happens at three levels, and picking the right one saves a surprising amount of unnecessary development.

Three levels of Odoo reporting: user-built views, printed QWeb documents, and new models or SQL views

Views your team builds themselves. List, pivot and graph views can be filtered, grouped and saved by anyone with the right access. Plenty of custom report requests get sorted here in ten minutes.

Printed documents. Quotes, invoices, delivery notes and purchase orders are QWeb templates. They can be restyled to your brand or rebuilt entirely to meet legal and customer requirements. Routine work.

Numbers that genuinely don't exist yet. When the figure you want isn't anywhere in standard Odoo, it needs building. Usually a new model, or a SQL view exposed read-only for speed. Margin across landed cost, stock ageing by location, supplier on-time performance, true cost to serve. None of those come out of the box in the shape a particular business wants them.

What can Odoo automate on its own?

Automated actions fire when a record is created, updated or deleted, or on a time condition. They can update fields, send email, create activities, or run server actions. Scheduled actions handle recurring jobs. Between them a lot of manual chasing just disappears. Reorder alerts, follow-ups on quotes that have gone quiet, approval reminders, expiry warnings.

Automation is also where quiet damage gets done. An action that writes to records in a loop, or triggers another automation, can cause performance problems and data changes nobody can trace later. Automations deserve the same test-database treatment as code.

What can Odoo integrate with?

Odoo exposes an external API over XML-RPC and JSON-RPC, and custom controllers can add REST endpoints. In principle anything with an API can be connected. In practice we get asked about ecommerce platforms, payment providers, bank feeds, 3PL and shipping carriers, CRM, and industry-specific software.

The connection is the easy part. What separates an integration that runs for years from one that quietly corrupts your data is everything around it. Idempotent writes so a retry doesn't duplicate an order. Conflict resolution when both systems changed the same record. Dead-letter handling. Alerting loud enough that someone notices the same day instead of at month end.

We build and run one of these ourselves, the Live Odoo Connector, which keeps Shopify and Odoo in step in real time. The Shopify to Odoo integration page covers what syncs and how failures are handled, and there's a fuller Shopify Odoo integration guide if that's your situation. Most Odoo integration work, though, has nothing to do with a storefront at all.

Will your customisations survive an Odoo upgrade?

This should be asked before any customisation is approved. It usually isn't.

What survives an Odoo upgrade versus what breaks

Configuration carries across. So do Studio changes, because they're stored as data. So do custom modules built through inheritance and the documented APIs. All of it needs testing, but none of it should be a drama.

What doesn't carry across is direct edits to core Odoo files, modules leaning on framework internals that were never promised to stay put, and clever workarounds nobody wrote down. Those are cheap to build and expensive forever, because every upgrade turns into a rescue job.

The question we ask before writing anything: if this module were installed on a clean database of the next Odoo version, what would break, and would we find out automatically? If the answer is "we'd find out when someone complains", the design isn't finished.

Community or Enterprise: what changes for customisation?

Both editions expose the same external API, so integration work is identical either way. The differences that matter here are that Studio is Enterprise only, and that a handful of modules teams eventually want are too. Advanced inventory routes, full accounting automation, multi-company, quality management.

The sensible approach isn't to default to the bigger edition. It's to work out during the audit which of those features your actual workflow depends on. Paying for Enterprise you never touch is waste. Finding out three months in that your process needs a module you haven't got is worse.

How we approach Odoo customisation

We're engineers, so the bias is toward building things that last. Configuration first. Studio where it genuinely fits. Custom modules written properly when they're warranted. Everything built in a test database against your real workflow before it goes anywhere near production.

If you're weighing up a change, working out whether you need a developer at all, or trying to rescue customisations that break every time you upgrade, our Odoo practice page sets out how we run engagements. Or just tell us what you're trying to fix.

Odoo customisation FAQ

Is Odoo Studio included in Odoo Community?
No. Odoo Studio is an Odoo Enterprise feature and is not available in Odoo Community. On Community you can still change a great deal through configuration, developer mode, and custom modules, but the drag-and-drop Studio interface itself is Enterprise only. This is the single most common surprise for teams who start on Community and expect to customise visually.
Odoo Studio or a custom module: which should we use?
Use Studio for custom fields, view and form layout changes, simple automations, basic report tweaks, and new lightweight models. Use a custom module when you need real business logic, computed values with non-trivial rules, integration with an external system, performance-sensitive queries, or anything that must be version-controlled and deployed through a test database first. A practical rule: if you could not explain the change to a new starter in one sentence, it belongs in a module.
Do Odoo customisations break when you upgrade?
Properly written ones usually do not. Custom modules that extend Odoo through inheritance and the documented APIs survive version upgrades with modest adjustment. What breaks is direct modification of core Odoo files, undocumented workarounds, and modules that depend on internals the framework never promised to keep stable. Studio changes are stored as data and generally carry across, though views layered onto heavily changed core screens can need rework.
How much of Odoo can be changed without a developer?
More than most people expect. Users with the right access can add fields, rearrange forms and list views, build filters and grouped views, create pivot and graph reports, set up automated actions on record changes, design email templates, and configure approval flows, warehouse routes, and pricelists. The line is reached when a change needs conditional logic across several models, external data, or anything that has to be tested and rolled back safely.
Can Odoo reports and dashboards be customised?
Yes, at three levels. List, pivot and graph views can be built and saved by users directly. Printed documents such as quotations and invoices are QWeb templates and can be restyled or rebuilt to match your brand and legal requirements. Beyond that, custom reports can be written as new models or SQL views when the numbers you need do not exist anywhere in standard Odoo, which is common for margin, ageing, and supplier performance reporting.
Can Odoo connect to systems we already run?
Yes. Odoo exposes an external API over XML-RPC and JSON-RPC, and custom controllers can expose REST endpoints. In practice that means ecommerce platforms, payment providers, bank feeds, 3PL and shipping carriers, CRM systems, and industry-specific software can all be connected. The engineering that matters is not the connection itself but the retry logic, conflict handling, and failure alerting around it.
How long does an Odoo customisation project take?
A focused set of Studio changes and a handful of custom reports is usually days. A custom module carrying real business logic is typically one to three weeks including testing. A full implementation with migration and integrations runs four to eight weeks from audit to go-live. Data quality, not development, is what most often moves those dates.