Odoo Studio is arguably one of the most appealing tools in the Odoo ecosystem.
Accessible, visual and easy to pick up, it gives the illusion that anything is possible in a few clicks: create a field, modify a view, add an automation.
One demo later, everyone applauds.
But behind the scenes, a fragile mechanism can take shape… and break when you least expect it: migration, module update, database restore…
A no-code tool… but not without consequences
Odoo Studio lets you modify native Odoo models (such as contacts, quotations, sales orders) directly from the graphical interface. It adds fields, buttons and views without writing a single line of code.
But unlike standard Odoo modules, Studio does not formally declare its technical dependencies. And that is where the trouble starts.
Real example: when Studio becomes a trap
Imagine this scenario, encountered in many projects:
- You install a community module, for example to enrich the customer record or add industry-specific management.
- With Studio, you add a field to res.partner (the standard customer record) that points to a model of the community module.
- Everything works perfectly. Until the day…
…you migrate, or you update a module.
And then Odoo starts by loading the native models, including the Studio changes, since the latter are attached to those models as if they were standard code.
But the community module is not yet loaded at this stage. Result:
The Studio field points to a nonexistent model.
And Odoo crashes.
This is not a bug. It is Odoo's logic.
In a traditional module, you would have a clear declaration in __manifest__.py:
'depends': ['base', 'my_community_module']
But Studio records no dependency. It adds the field to the model… and does not care whether the target model is available at load time. Result: incomprehensible errors during migration, or worse, an unusable database after an update.
Migrations, updates, restores: same fight
This trap does not concern only major migrations (for example from version 17 to 18).
It can arise:
- during a simple community module update,
- after a database restore,
- or even when deploying to a test instance.
As soon as there is a loading mismatch between a community model and a Studio field that depends on it, the risk is there.
Our advice at Auguria
Because the tool is good but its use deserves method, here is our approach.
1. Use Studio for prototyping
Studio is perfect for testing an idea, building a mock-up in a customer workshop, showing a flow.
It is fast, reversible and expressive.
But it is not a reliable basis for building a lasting application foundation.
2. Once the idea is validated, turn it into a module
As soon as the need is validated, cleanly recode the feature in a traditional Odoo module:
- structured,
- versioned,
- controlled,
- with its dependencies declared.
It is more robust, cleaner… and above all painlessly migratable.
3. Never create a Studio field pointing to a community or custom model
This is the typical case that triggers migration errors: a field created with Studio that depends on a module not yet loaded.
Avoid at all costs. It is a golden rule we apply systematically.
What Studio does not tell you…
Studio gives the illusion that you can develop without a developer.
But a good information system has to be thought through, structured and documented.
And it has to be migrated.
At Auguria, we love flexibility. But not at the expense of reliability.
We like agility. But not without a framework.
And above all, we prefer to tell the truth about tools. Even when they are appealing.
In summary
Odoo Studio is a great lever for fast innovation.
But without discipline, it becomes a source of technical debt and future roadblocks.
If you want speed and robustness, then you need to combine Studio with a real project method.
And if you doubt, or hesitate between Studio, a custom module and good old lines of code…
Call us.
We won't tinker. We will build.