Campos personalizados de Odoo vs Studio vs Módulo: Árbol de decisiones 2026

When a business requirement comes in — "we need to track an additional date on the sales order" or "we need a new field to capture customer industry segment" — Odoo offers three implementation paths: Settings-level custom fields, Studio customization, or a hand-written Python module. Each has different costs, capabilities, performance, and long-term maintenance implications. Picking wrong creates technical debt that compounds.

This article gives you a clear decision tree. ECOSIRE has watched hundreds of customization decisions play out across Odoo deployments — the wrong choice shows up 12-18 months later when a migration or audit forces a refactor.

Key Takeaways

• "Custom fields" via Settings UI are limited but instant — best for simple text/date/number additions
• Studio handles 80% of customization needs without code, but has performance and capability ceilings
• Custom Python modules are the right choice for: complex logic, performance-critical fields, frontend changes, integrations
• Studio outputs a real module — version-control-able and migration-safe
• Performance: custom Python field > Studio computed > Studio sandboxed expression
• Total cost of ownership: Studio cheaper short-term, custom module cheaper long-term for complex needs
• Mixing approaches in the same database is fine; documentation matters more than uniformity

The three paths

Path 1: Settings UI custom fields

The simplest. In developer mode, certain models expose "Custom Fields" in their settings. Add a field, give it a type, save. No code, no module, no deploy.

What it can do:

• Char, integer, float, boolean, date, datetime, selection
• Field appears on the form view automatically (default location)
• Persisted in the model's table

What it can't do:

• Computed fields
• Relations (many2one, many2many)
• Custom view placement (you take the default)
• Custom validation
• Migration to other databases

Cost: 5 minutes. Reversibility: high (just remove the field).

Path 2: Odoo Studio

Studio is the no-code/low-code layer. It can do most things a developer would code, but through a browser UI.

What it can do:

• All field types including relations
• Custom view layouts (drag-drop)
• Computed fields with sandboxed Python expressions
• Automated actions (triggers, schedules, webhooks)
• Build a small standalone app
• Output exports as a real, importable module

What it can't do:

• Complex computed logic (loops, multi-hop joins)
• Custom QWeb reports
• Override stock workflow methods
• Frontend customization (custom OWL widgets)
• Integration with external APIs beyond webhook
• Performance-critical fields

Cost: 30 minutes to half a day per change. Reversibility: medium (Studio module export + uninstall).

Path 3: Custom Python module

The full developer path. Code in Python, XML, JS, deploy via git.

What it can do:

• Anything Odoo's Python framework supports
• Complex business logic
• Integration with external services
• Custom frontend (OWL widgets, reports)
• Performance-tuned with proper indexing

What it can't do:

• Be built without a developer
• Be modified by non-technical users

Cost: 1-5 days per feature. Reversibility: medium (uninstall module, but data may persist).

The decision tree

Walk through these questions for any customization request:

Q1: Is the change just adding a simple data field (text, date, number, boolean)?
├── YES → Q2
└── NO  → SKIP TO Q4 (Studio or module)

Q2: Will it be used purely for display/search, no computation?
├── YES → SETTINGS CUSTOM FIELD
└── NO  → SKIP TO Q4

Q3: (skip — wraps to Q4)

Q4: Does the customization involve any of:
   - Custom Python logic (validation, computation, side effects)
   - Custom QWeb reports
   - Custom OWL widgets / frontend
   - External API integration
   - Performance-critical paths
   - Override of stock workflow methods?
├── YES → CUSTOM PYTHON MODULE
└── NO  → STUDIO

For 80% of customization requests, the answer is Studio. For 15%, settings custom fields. For 5%, custom modules — but those 5% are usually the high-impact features that move the business.

Performance comparison

We benchmarked the same computed-field logic implemented three ways on a 5,000-record res.partner set:

The sandbox overhead is real. For frequently-read fields, store the Studio computation; for compute logic in hot paths, use a custom module.

Capability comparison

Migration risk

Custom fields added via Settings UI generally migrate cleanly across versions because Odoo's openupgrade scripts handle generic field types. But:

• Selection field options can drift if option labels change in upgrades
• Field placement defaults can shift if the form view structure changes

Studio modules carry their own changelog, making them more migration-safe than ad-hoc custom fields.

Custom Python modules are explicit — your migration is what you write, and breaking changes are caught in code review.

Total cost of ownership

A simple chart for a 100-developer-hour customization budget over 3 years:

Studio is cheaper at first; custom modules amortize when you need their capabilities. The crossover point is roughly: if a feature requires more than ~3 customizations or any logic that exceeds Studio's sandbox, a module is cheaper long-term.

Common scenarios — the right answer

Mixing approaches

It's fine to use all three in one database. ECOSIRE's typical client deployment has:

• ~10 settings-level custom fields (simple data captures)
• ~5-15 Studio customizations (forms, automated actions, simple apps)
• ~5-30 custom Python modules (workflow logic, integrations, complex features)

The risk isn't mixing — it's losing track. Maintain a simple registry:

| Customization | Path | Owner | Created | Reason |
|---------------|------|-------|---------|--------|
| partner.industry | Custom Field | Sales Team | 2026-01-15 | Industry segmentation |
| sale.order auto-tag VIP | Studio | Sales Ops | 2026-02-08 | High-value flag |
| custom_invoice_qr | Module | Dev Team | 2026-03-01 | QR for payment portal |

Audit yearly; deprecated customizations are technical debt.

When to escalate from Studio to module

Escalation triggers — if any apply, refactor Studio → module:

1. The Studio computed expression exceeds 10 lines
2. The customization needs a custom widget
3. The performance is measurably impacting users
4. The customization needs to integrate with an external API
5. The customization needs unit tests
6. The customization needs to be applied across multiple Odoo databases

Plan to migrate within a sprint; the longer Studio carries the load, the harder the eventual rewrite.

Frequently Asked Questions

Can I migrate a Studio customization to a Python module?

Yes, with effort. Export the Studio module from the customization → unzip → review the generated Python/XML → integrate into your custom addon → uninstall the Studio module. The Studio output is real Odoo code, not magic, so it's a translation rather than a rewrite.

Will Studio customizations slow down Odoo?

In aggregate, yes — each Studio computed field with store=False adds compute overhead on read. Audit yearly. Convert frequently-read Studio fields to store=True or migrate them to native code.

What about UI customizations — can Studio handle a complete page redesign?

For form views, kanban, and list customizations, Studio is sufficient. For new custom pages with OWL components or integrations with external dashboards, you need a module. The line is "is it a standard Odoo view type?" — yes → Studio is fine; no → module.

Are Settings custom fields safe to use in production?

Yes for simple data captures. They store in the database normally and survive upgrades. Avoid them for fields that drive critical business logic — those deserve the explicit definition of a module.

How do I document customizations for future developers?

Maintain a CUSTOMIZATIONS.md in your client repo, updated when any of the three paths adds a new customization. Include: the path used, the business reason, who owns it, and a date. Future migrations and refactors save days of archaeology with a 30-minute monthly habit.

---

Choosing between Settings, Studio, and custom modules is one of the highest-leverage decisions in an Odoo deployment. ECOSIRE's Odoo implementation team helps clients pick the right path per requirement and maintains the customization registry across multi-year engagements. See our Odoo customization service for module development or our Odoo consultancy service for architecture decisions on which path to take.