If you’ve ever opened Odoo Studio, dragged a field onto a form, and then wondered whether you just created a permanent database column or something more temporary — you’re not alone. That confusion has been one of Studio’s quiet friction points for years.
That just changed. Odoo shipped a comprehensive rewrite of Studio’s field management documentation that doesn’t just polish the language — it restructures the entire way fields are explained, categorized, and managed within the platform.
Studio Fields and Property Fields Are No Longer the Same Conversation
The biggest conceptual shift in this update is the explicit distinction between Studio fields and property fields. Previously, these two concepts lived in the same documentation space with minimal differentiation. Now they have separate explanations, separate use cases, and a clear technical boundary.
Here’s the difference that matters: when you create a field through Studio, it becomes a real column in your Odoo database. It exists on every record of that model, everywhere, always. If you add a “Deadline” field to a task form using Studio, every task in your entire database gets that field.
Property fields work differently. They act as pseudo-fields that are shared only by records linked to the same parent. Add a “Special Instructions” property field to a task, and it shows up in all tasks within that specific project — but tasks in other projects remain unaffected. No new database column gets created.
This distinction matters enormously for businesses managing large databases. Studio fields are powerful but permanent. Property fields are flexible and scoped. Choosing the wrong one can mean either cluttering your database schema with columns you don’t need everywhere, or losing data context because a property field doesn’t persist across parent boundaries.
Field Types Get a Proper Taxonomy
The updated documentation now organizes Odoo’s 15 technical field types (available as 20 options in Studio, since some types appear with different default widgets) into two clear categories: simple fields and relational fields.
Simple fields hold basic values — text, numbers, dates, files, booleans. Relational fields link records together across models, enabling the kind of interconnected data architecture that makes an ERP actually useful. Many-to-one, one-to-many, many-to-many — each has its own behavior, its own widget options, and its own implications for how data flows through the system.
Previously, all 20 field options were presented as a flat list. The new structure groups them logically, which means users who are building custom workflows in Studio can now make informed decisions about field types before committing to a schema change they might regret later.
Adding, Modifying, and Removing Fields Now Has a Playbook
The rewrite introduces four explicit operations with their own dedicated sections:
- Adding new fields— Drag-and-drop onto form or list views, with guidance on which views support new field creation (form and list only).
- Adding existing fields— Pulling fields that already exist on a model into any view. This is different from creating new ones, and the documentation now treats them as separate workflows.
- Modifying field properties— Changing labels, help text, default values, visibility conditions, and widget types on fields that are already in place.
- Removing fields from views— Pulling a field off a view without deleting it from the database entirely.
Each of these had been possible before, but the documentation treated them as variations of the same action. Separating them acknowledges a reality that Studio users have always known: adding a brand-new field and surfacing an existing one on a different view are fundamentally different decisions with different consequences.
Dashboard Module Gets a Necessary Installation Callout
In a smaller but useful change, the “My Dashboard” feature in Odoo now includes an explicit note about module dependencies. To access the dashboard, you need both the Dashboards module and the Spreadsheet Dashboard module installed.
This sounds obvious, but it wasn’t documented before. Users who had only the Spreadsheet Dashboard module installed would navigate to the dashboard and wonder why certain features were missing or inaccessible. The new note catches this before it becomes a support ticket.
For teams that rely on AI-powered analytics layered on top of Odoo dashboards, having both modules properly configured is a prerequisite for getting clean data into your reporting pipeline.
Why This Matters Beyond Documentation
Studio is one of Odoo’s most powerful differentiators — it’s what lets non-developers customize an enterprise ERP without writing code. But power without clarity is just confusion wearing a drag-and-drop interface.
This rewrite doesn’t add new features to Studio. It makes the existing features understandable. And for businesses making schema decisions that will affect their database for years, understanding is worth more than another checkbox on a feature list.
If you’re building custom workflows with Studio or evaluating whether to use Odoo’s automation tools alongside custom fields, this updated documentation is worth reading before you start dragging anything onto a form.