# Odoo Studio Custom Fields: Export, x_studio Names and Upgrade Risk > Source: https://netray.co/erp-help/odoo-studio-custom-fields-x-studio-export-and-upgrade > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Odoo Studio saves your changes as data in the database: custom fields named x_studio_*, edited views stored as inherited ir.ui.view records, and automation rules. You can export them as a module via Studio's Export button, but upgrades can break Studio views when the base view changes, and Studio is not a substitute for version-controlled code on complex logic. ## Kind how-to ## System small-erp ## Erp Odoo Enterprise ## Module Odoo Studio / Customization ## Query Odoo Studio custom fields export upgrade x_studio ## Alternate Queries - odoo studio customizations lost after upgrade - odoo studio export to module - odoo x_studio fields in custom module - odoo studio vs custom module which to use ## Applies To Odoo Enterprise 15, 16, 17 and 18 with the Studio app (Odoo Online, Odoo.sh and on-premise Enterprise) ## Steps ### How to export and protect Studio changes **Items:** - Open Studio from any app and note which models you modified. Customizations are scoped by model, not by app. - In Studio, open the three-dot or Customizations menu, choose Export, and download the zip. This creates a module containing data for the fields, views, actions and automations, with xml ids prefixed studio_customization. - Review the zip: data/ir_model_fields.xml, ir_ui_view.xml and any ir_actions_server.xml. Read the views and the server actions for hard-coded ids and company-specific values. - Install the exported module on a staging database to verify it recreates the fields and views without errors. - Before an upgrade, take a copy of the database, run the upgrade on it, then open each customized view. Broken views raise 'Element cannot be located in parent view' errors. - Fix by editing the inherited view in Settings > Technical > User Interface > Views, searching by name with Studio in it, and correcting the xpath, or by re-doing the change in Studio. - For complex logic, move computed fields and automation code into a proper custom module kept in Git and stop adding it in Studio. ## Sections ### What Studio actually creates **Body:** A field added in Studio is a normal row in ir_model_fields with state set to manual and a technical name beginning x_studio_ (earlier versions used x_ with other prefixes). Because it is stored as a manual field, the database column is created on the model table, for example x_studio_priority on sale_order, and appears in the ORM like any field. Views changed in Studio are saved as inherited views on top of the original, with an xpath to place or hide elements. The base view stays untouched, so the customization survives module updates until the base structure changes under the xpath. Automations built in Studio become base.automation records with server actions, which may contain Python snippets that run on create or write. These live in the database, are not under source control, and run with the permissions defined on the action. **Code:** -- List Studio and other manual fields on a model SELECT name, field_description->>'en_US' AS label, ttype, state FROM ir_model_fields WHERE model = 'sale.order' AND state = 'manual' ORDER BY name; -- Studio views SELECT id, name, model, inherit_id, active FROM ir_ui_view WHERE name ILIKE '%studio%' AND active; ### Exporting and re-importing **Body:** The Studio export module is intended to move customizations from a sandbox or staging database to production, or into a custom module you maintain. It uses xml ids tied to the customization so re-importing updates existing records rather than duplicating them. It exports definitions, not the data held in those fields. Populate x_studio_ fields in the target database through import or the API. Exports are also limited in what they capture: reports edited in Studio, access rights and some settings may need verification after import. Do not hand-edit the generated xml ids. Studio relies on them to recognise its own records, and rewriting them leads to duplicate fields on the next export. ### What breaks at upgrade **Body:** Major version upgrades through Odoo's upgrade platform or openupgrade rewrite standard views. A Studio xpath that targets a field or group which no longer exists produces an error on loading that view, and the form becomes unusable for the model. Because customizations are layered, one broken inherited view can take down a whole screen. Reports edited in Studio are stored as QWeb view overrides and fail in the same way when the base report template changes. Test PDFs after upgrade, not only the web forms. Studio fields themselves usually migrate cleanly because they are plain columns. The risk is on views, reports, automations that reference removed fields or methods, and computed fields written as Python in server actions. ### Studio or a custom module? **Body:** Studio is a good fit for adding a few fields, simple view layouts, approvals and light automations. It is hard to review, diff and test, and it is only available on Enterprise. Move to a custom module when you need relational logic, computed fields with dependencies, constraints, unit tests, a CI pipeline or deployment across several databases. A common pattern is to prototype in Studio, export, then clean up the generated XML into a maintained module and uninstall the Studio customization. ## Pitfalls - Adding critical business logic in Studio automations with no source control or tests. - Skipping an upgrade rehearsal on a database copy and finding broken views in production. - Renaming x_studio_ fields in SQL, which breaks stored views, filters and automations that reference them by name. - Assuming the export carries field data, not just definitions. - Editing PDF reports in Studio and not retesting them after a version change. ## Ai Angle An assistant that can read the ir_model_fields, ir_ui_view and base_automation tables can produce an inventory of what Studio changed, which views reference which x_studio_ fields, and which of them an upgrade is likely to affect. That makes the rehearsal faster. Generating the cleaned-up module is a drafting task with a developer reviewing it. Applying any change to production views remains a human-approved step. ## Faq ### Does Odoo Studio work on Community edition? **Answer:** No. Studio is an Enterprise app. Community users add fields through developer mode (Settings > Technical > Database Structure > Fields, which creates manual fields) or through a custom module. ### Will Studio customizations survive an upgrade? **Answer:** Fields usually do. Views, reports and automations can break if the base view changes under them. Always rehearse the upgrade on a database copy and review every customized screen before going live. ### Can I rename a Studio field? **Answer:** You can change the label freely. Changing the technical name x_studio_* is risky since views, filters, reports and automations refer to it. Create a new field and migrate the data instead of renaming it. ### How do I move Studio changes from test to production? **Answer:** Use Studio's Export on the test database, then import the generated module in production, or install it as an app. Verify the result and populate field data separately. Odoo.sh teams often commit the cleaned module to Git instead. ## Search terms odoo studio export, odoo x_studio fields, odoo studio upgrade broken view, odoo studio vs custom module, odoo studio customizations module, odoo manual fields ir_model_fields, odoo studio automation base.automation, odoo studio report upgrade --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json