Customizing apps with Odoo Studio

How Studio stores your customizations

Before you customize anything, understand where the work goes. The moment you make a change in Studio, Odoo creates (or updates) an internal customization module in the database that holds every field, view, menu, automation rule, webhook, approval rule, and report you add. Studio does not edit Odoo’s core source files — it writes records that Odoo merges with standard apps at runtime. That design is what makes Studio reversible, fast to iterate on, and portable between databases once you export it.

Because customizations live as data rather than code, they behave differently from a hand-written Python module. A Studio change is visible immediately, with no restart and no deploy step. The flip side is that there is no source file to diff, no automated test to run, and no code-review gate by default — the customization exists only in the database until you export a ZIP. Odoo’s own docs and partner practice treat that export as the control path: Studio has no built-in VCS.

Studio is Enterprise-only; it is not available on Odoo Community. On Community, the equivalent work falls to Developer Mode plus custom Python modules, which is why many SMEs treat Studio as a deciding factor when choosing editions. If you want the broader what-is-it framing, see our Odoo Studio guide; this page is the hands-on customization counterpart.

Hosting changes how far you can push customization. On Odoo Online (SaaS), Studio is available but custom server-side Python modules and third-party installable apps are restricted — Studio is often the ceiling for deep changes. On Odoo.sh and on-premise, you can install proper modules, run Git-based CI, and promote Studio exports into real addons. Plan multi-env workflows for .sh/on-prem; treat Online Studio as additive UI only unless you are ready to move hosting later.

Configuration vs Studio vs custom module vs third-party apps

Most failed Studio projects start with the wrong tool for the job. Fit-to-standard configuration (Settings, stages, routes, fiscal positions, security groups, email templates) is almost always the safest path: no new schema, lowest upgrade risk, easiest support. Studio sits next: additive fields, layout changes, simple automations, button approval steps, light PDF rebranding. Custom modules own business logic, integrations, performance-critical code, and anything that needs tests and review. Third-party App Store modules fill vertical gaps when a maintained app already solves the problem better than a one-off build.

Use the matrix below as a standing decision gate on every ticket. The upgrade-risk column is the one teams skip — and the one that bills them later. Practitioners and partners consistently frame Studio as temporary debt if it is never exported and never reviewed; modular ownership beats plugin sprawl and untracked database clicks.

Adding custom fields: types, AI fields, and real examples

Fields are the most common Studio customization. When you open Studio and drag a new field onto a form, the picker offers a broad set of convenience types even though the underlying ORM has a smaller core set — Studio surfaces friendlier variants (HTML, percentage, widget-specific options) so non-developers pick the right control without reading ORM docs. Odoo 19 also adds AI fields via Studio: drag an AI Field onto a form, write a prompt that can reference other fields on the record, and generate summaries, descriptions, or contextual text on demand. AI fields are Enterprise-gated with the rest of Odoo AI; treat them as assistive content, not as the source of truth for compliance data.

The practical split is three families. Scalar fields hold a single value — text, integer, float, monetary, boolean, date, datetime, selection, and HTML. Relational fields link records: Many2one for one parent, One2many for children on the parent, Many2many for unbounded tags-style links. Computed and Related fields derive values from formulas or parent paths. Relational fields earn most of the business value; uncontrolled Many2one sprawl on high-volume tables (stock moves, account move lines) slows lists and reports. Stored computed fields that depend on other computed fields cascade recomputations on every write — set dependencies precisely and keep display-only values non-stored.

Concrete example — sales delivery window: open Sales → a sales order → toggle Studio. Drag a Date field, label it Delivery Window Start, technical name will be something like x_studio_delivery_window_start. Add a second Date for end. Place both on a new “Logistics” notebook tab with Tabs and Columns. Open the Search view and add both fields so users can filter. That is a ten-minute Studio job; do not hire a developer for it. Anti-pattern: building the same delivery-window logic as Studio Python in an Execute Code action that also posts to a carrier API — that belongs in a custom module with tests.

Redesigning views: forms, lists, kanban, and search

Views are how users see and edit data, and Studio’s drag-and-drop editor is where most of the visible value of customization shows up. Studio can modify every view type Odoo ships: form, list (tree), kanban, calendar, graph, pivot, map, gantt, and search. You can reorder fields, group them into tabs, hide columns, add fields you just created, and restructure notebooks without hand-editing XML — though Studio still generates brittle xpath under the hood, which is why view changes are a frequent upgrade headache.

For forms, Studio gives you Tabs and Columns so you can structure notebooks and multi-column grids. The same panel lets you toggle Can Create, Can Edit, and Can Delete per view — a quick way to make a list read-only for a process without writing access rules. For kanban, control grouped columns, card fields, and quick-create behaviour so a generic pipeline matches how the team actually works. To change the default view of a model, open Studio → Views, open the ellipsis on the desired view, and Set as Default.

Search views are the quiet workhorse. They decide which fields users can filter and group by, which custom filters appear as buttons, and what the default grouping is. A common miss: teams add a field in Studio, put it on the form, and forget search — then nobody uses the field. Make exposing filterable fields part of the standard field-creation routine. With Developer Mode on, you can also open the View tab and inspect or lightly edit the generated XML when Studio’s xpath gets too specific for a future upgrade.

Menus, window actions, and PDF reports

Once you have new fields or a new model, users have to reach it. Studio’s menu editor lets you add, reorder, rename, and restructure menu items and the window actions behind them. A window action loads a view — model, default filters, default view type, and domain. When you add a menu for a custom app or model, Studio creates both the menu item and its window action; tune the action to open a pre-filtered list or a specific kanban by default.

Naming and grouping menus matters. Odoo’s app launcher is the primary navigation surface, so a flat dump of custom menus becomes unusable. Nest customizations under the app they extend (a CRM extension under CRM, not as a new top-level app) and name menus after the business object, not the team that asked for it.

PDF reports are a first-class Studio surface in current docs (alongside fields, views, models, automation, webhooks, and approval rules). You can edit existing PDFs — invoices, quotations, delivery slips — or create new ones, adjust the default document layout, and place custom fields on the template without hand-writing QWeb for simple rebrands. Heavily conditional layouts, multi-language legal blocks, or pixel-perfect compliance documents still warrant a custom QWeb report module; the visual editor covers the common rebrand-and-add-column cases in an afternoon.

Automation rules, webhooks, and approval rules

Studio automation rules (Automated Actions in older versions; renamed in recent releases) execute one or more predefined actions when a trigger fires — for example create an activity when a field hits a value, or archive a record seven days after its last update. Official Odoo 19 docs also document webhooks and approval rules as Studio surfaces next to automation.

Every automation rule has three parts: the Model, the Trigger (on create, update, create-or-update, delete, timed condition, UI action, email/SMS event, or On webhook), and the Actions (create activity, update fields, send email/SMS, create another record, sandboxed Execute Code, sequences, templates). A single rule can say: when a sales order moves to Won, set close date, create a fulfilment task, and email a thank-you template — entirely from the UI.

Webhooks let an external system POST a payload to a Studio-generated URL so Odoo can update records in near real time — for example sync inventory when an external POS validates an order. Docs warn that misconfigured webhooks can disrupt the database and are hard to reverse; involve a developer or architect before production webhooks. Approval rules attach multi-step approvers to buttons: open Studio on the view, select the button, and Add an approval step in Properties — useful for “manager must approve Confirm” without a full Approvals app rebuild.

Anti-patterns: stacking many On update rules on stock.move or account.move.line; using Execute Code as a dump for multi-model transactions; wiring webhooks without auth, idempotency, or logging. Those patterns are why partners still recommend custom modules for anything load-bearing.

Two worked customizations (and the anti-patterns next to them)

Example A — CRM “Next review date” with reminder: open CRM → opportunity form → Studio. Add a Date field Next Review Date. Place it near the expected closing date. Create an automation rule on crm.lead: trigger On update when Next Review Date is set; action Create activity for the salesperson three days before that date (use a timed condition or a second scheduled rule if your build prefers time-based triggers). Expose Next Review Date on the search view with a “Review this week” filter. Whole change stays in Studio, export weekly, re-test after upgrades.

Example B — Purchase Confirm needs dual approval over a threshold: open a purchase order form in Studio, select the Confirm button, Add an approval step for the Purchase Manager group, and add a second step for Finance when amount_total exceeds your threshold (domain on the rule). This uses Studio approval rules instead of inventing a parallel workflow model. If thresholds become multi-currency, multi-company, and delegated-approver graphs, stop — that is Approvals app configuration plus a custom module, not more Studio clicks.

Anti-patterns to ban in code review (even for no-code): referencing x_studio_* fields from a custom Python module (you will regret the coupling on the next export or upgrade); editing the same view in both Studio and a custom module inheritance; putting Execute Code on hot models without a domain; prototyping forever in production without export; treating Studio as free because Enterprise already pays for it — undocumented Studio still costs upgrade time.

Where Studio hits its limits (including Online SaaS)

Studio is powerful but not unbounded. Complex business logic that spans multiple records in one transaction, real-time outbound integrations with full OAuth and retry semantics, or anything that must be unit-tested and code-reviewed belongs in a custom Python module. Studio’s Execute Code action can run Python, but it is not a substitute for a version-controlled module with tests.

Scale and performance are the second wall. Studio customizations are stored as data and merged at runtime — fine at SME volumes, expensive when computed fields, onchanges, or automation rules fire across millions of stock moves or journal items. There is no query plan to inspect and no index to add in the visual editor; the fix is a module where you control SQL, indexes, and recomputation strategy.

Lifecycle is the third wall. Studio has no built-in code review, no test suite, and no VCS until you export. Partners and forum practitioners report the same pattern: excellent for quick adjustments and prototypes; modular, code-first work is safer at scale. On Odoo Online specifically, you generally cannot install arbitrary custom modules or third-party server apps the way you can on Odoo.sh/on-prem — Studio (plus configuration) is the practical ceiling. If your roadmap needs deep custom modules, budget a move to Odoo.sh or on-premise rather than forcing everything into Studio.

• →Complex multi-record business logic — use a custom module
• →Performance-critical writes or computations on large tables — use a custom module
• →External integrations with auth, retries, and mapping — use a custom module (or carefully designed webhooks with technical ownership)
• →Anything that needs unit tests, code review, and native Git CI — use a custom module
• →Deep customization on Odoo Online beyond Studio — plan hosting change to Odoo.sh/on-prem

Upgrade safety and the technical-debt trade-off

Studio stores customizations as data, so the upgrade story is real but nuanced. Light, well-structured Studio work often survives a major-version upgrade because migration scripts can carry data records forward — a point often made when comparing Studio to hand-written modules that need explicit migration each major version. Heavy, undocumented Studio use is invisible debt: no diff against release notes, and no automated way to know which xpath will break when a core view changes. Studio generates highly specific view xpath; partners warn that counting nodes during upgrades is a common pain.

Four habits keep Studio productive across upgrades. First, keep a living inventory of every Studio customization by app so the upgrade planner knows what to re-test. Second, export Studio work as a module periodically so a real artifact lives in Git. Third, treat anything that touches core accounting, inventory valuation, or multi-company logic as a custom-module candidate from day one. Fourth, before any major-version upgrade, re-test every Studio customization in staging — never assume it survived.

Do not mix custom modules that depend on x_studio_* fields. Forum best-practice answers are blunt: you will regret it. If a Studio field must become permanent, migrate it into a module with the same technical name and type so the DB column is reused, then remove the Studio definition carefully. That migration path is how teams graduate prototypes without data loss.

This is the same configuration-versus-customization discipline every ERP needs. For the vendor-neutral framework, our ERP customization vs configuration guide covers the decision criteria for Odoo and Dynamics 365. Short version: prefer configuration, use Studio for additive no-code changes, reserve code for load-bearing logic.

Export → Git → multi-env promotion (Studio has no built-in VCS)

The bridge between Studio and controlled delivery is export. Studio has no native version control. The control path is: export a ZIP of the Studio customization module, commit that ZIP’s contents (or the extracted module) to Git, and promote through environments via import or addon install — not by re-clicking production by hand.

Practical export paths used in the field: from Studio, use Import/Export to download the customization module ZIP; or via Settings → Technical → Studio-related module tools (wording varies slightly by version) find the Studio-generated module and Export. On a client delivery, common successful flow is: export ZIP on the build database → open Studio on the target → Import/Upload the ZIP. Alternative for .sh/on-prem: extract the ZIP into the custom addons path, restart or update the app list, and install/upgrade the module. Database backup/restore also moves Studio state, but that is a blunt instrument for multi-env promotion.

Recommended multi-env playbook: (1) customize only on a development or staging database, never first on production; (2) export after each meaningful change set; (3) commit the module snapshot to Git with a human-readable note of what changed; (4) import or install on staging and run a regression checklist (forms, automations, reports, approvals); (5) promote the same artifact to production; (6) when logic outgrows Studio, hand the exported module to a developer as the working reference and rewrite as a clean custom module with tests. Export is version- and base-app-tied — it is transport and versioning, not a magic cross-version migrator.

For the code-first alternative, our Odoo custom module development guide covers model and view inheritance, major-version migration effort, and how to structure modules so they upgrade cleanly. The SME pattern that lasts: prototype in Studio, export to Git early, promote anything load-bearing into a module — use both tools, not an either/or fight.

A practical customization decision workflow

Pulling the playbook together, one workflow covers almost every SME request. Step one — fit-to-standard: check Settings, fiscal positions, warehouse routes, security groups, stages, and templates before customizing. Most “we just need different behaviour” tickets die here.

Step two — Studio for additive no-code work: fields (including Odoo 19 AI fields when appropriate), view restructuring, menus, PDF layout, straightforward automation, button approval steps, and carefully owned webhooks. Ship fast, reverse easily, export to Git the same week.

Step three — escalation test: multi-record logic, external integration, performance at scale, multi-company valuation, or anything that must be tested and reviewed → custom Python module (or a maintained third-party app). Use export as the hand-off so the prototype is not wasted. On Online SaaS, if step three is permanent, plan Odoo.sh/on-prem rather than stacking fragile Studio Python.

Throughout, run governance: inventory every change, periodic exports, special caution on accounting and valuation, no x_studio_* leakage into custom modules, and staging re-tests before upgrades. Done this way, Studio is a controlled accelerator. The same ladder appears on other stacks — on Dynamics 365 the no-code layer is Power Platform — even when the product names differ.

Frequently asked questions