Open any app in an Enterprise database, click the Toggle Studio icon, and the screen you were looking at becomes editable. Drag a field onto the form, rename a column in the list, add a filter. There’s no deploy step: the change applies to every user of that database. That immediacy is why admins like it and why developers get nervous about it.
What it can change
Per Odoo’s own documentation, Studio covers fields and widgets, views, models, automation rules, webhooks, PDF reports, approval rules and security rules. When you create a new model or app, it offers optional features like chatter, pipeline stages, archiving and a company field, each of which adds the fields and views that usually go with it.
Automation rules deserve a special mention because one of their actions is Execute Code. That’s Python, typed into a text field in the browser, with env, record, records and a few helper libraries available. It’s the point where “no-code” stops being accurate.
Where the work is stored
Studio doesn’t write Python files or a folder you can open in an editor. Every change is a record in the database. A new field gets a technical name starting with x_studio_, and Odoo requires at least an x_ prefix on any custom field. View changes are inherited views that use XPath against the standard view, just as a developer’s would, only stored in the database rather than in a module.
All of it is attached to a module named studio_customization, which Odoo adds to the database the first time you customize something.
Moving customizations to another database
Studio has its own Export button. It downloads a ZIP containing the studio_customization module, optionally with data or demo data from selected models, and the Import button on another database installs it.
Two conditions come with that, straight from the docs. The destination must run the same Odoo version and have the same apps and modules installed. Studio doesn’t list those underlying modules as dependencies of the exported module, so checking that is on you before you click Install.
What you get is a module of exported records, not an Odoo addon with models and tests you’d want to maintain by hand. It’s a transfer mechanism, not a way to turn Studio work into source code.
Edition and hosting
Studio is Enterprise only. Community databases don’t have it, so changes there happen in modules or through the technical menus in developer mode.
On Odoo Online it matters more. Odoo Online databases don’t support custom modules, so Studio (with automation rules for logic) is the main customization tool you have there. Odoo’s pricing plans also affect it: installing Studio on a Standard plan database triggers an upsell to the Custom plan, and maintenance of custom code in Execute Code actions isn’t included in either plan.
On Odoo.sh and self-hosted Enterprise you can mix Studio with your own modules. Whether a given change belongs in Studio or in code is a judgment call, and we’ve written up when Studio is enough and when you need a module. erpfly works on the module side of that line, so if you’re adjusting standard Odoo apps with code rather than clicks, see Odoo customization.