System design
Odoo configuration vs customization: where to draw the line
Choose the smallest appropriate change that meets a real business need—and be clear about how it will be tested, documented and maintained.
No code does not mean no customization
Standard configuration uses existing settings and supported workflows. Studio is a customization toolbox: it can change fields, views, reports, rules and other behavior without conventional module development. A custom module adds or extends behavior through code. These are different approaches, not a ranking from good to bad.
Compare the available approaches
| Approach | What it means | What to evaluate |
|---|---|---|
| Standard configuration | Use existing settings and processes | Workflow fit, permissions and documented settings |
| Studio customization | Change supported fields, screens, reports or rules | Expressiveness, subscription, dependencies and tests |
| Custom module | Implement or extend behavior through code | Hosting, ownership, maintenance and compatibility |
| Third-party module | Adopt a maintained package from another supplier | License, version support, dependencies and exit plan |
| External integration | Exchange data with another system | Mapping, security, retries and reconciliation |
Demonstrate the gap first
Describe the decision or task that the current workflow cannot handle. Use a sample record and show what the user needs to do. Ask whether an existing feature or a reasonable process adjustment already solves it before specifying a change.
For example, an extra customer attribute and an approval rule are two requirements that should be evaluated separately. The first may concern data capture; the second may affect responsibility and permissions. The appropriate solution depends on the actual rule, edition and version. This is an illustrative example, not a promise that a particular mechanism will fit every case.
Hosting and subscription are part of the decision
Odoo Online does not support custom modules. Odoo.sh provides a repository-based route for community and custom modules. Studio has separate subscription implications: Odoo describes a move from Standard to Custom when Studio is installed. Verify current terms and the selected deployment before approving an approach.
A change needs an owner after launch
Record why the change exists, what it touches and how correct behavior is tested. Include roles, edge cases, reports and connected systems. Do not assume that a change is maintenance-free because it was created without code.
For upgrades, Odoo documents compatibility work and testing for custom modules. A technically successful installation is not proof that a business workflow still works. Plan representative transactions and make the maintenance responsibility part of the original agreement.
Before approving a change
- What specific business problem does it solve?
- Which standard behavior was evaluated, and why was it insufficient?
- What data, access rules and other workflows could it affect?
- Who will accept the result and maintain the documentation?
- What happens on upgrade, module retirement or supplier change?
Is configuration always cheaper?
Not necessarily. Effort depends on the process, data and testing required. Compare complete alternatives against the same requirement and responsibilities.
Should we customize everything to match the old system?
Review the reason for each existing rule. Preserve necessary controls, but test whether the standard process can remove avoidable complexity before rebuilding it.
Related reading
Sources & further reading
A useful next step
Bring one real workflow.
A sample document, the systems you use and the decision you need to make are enough to start a focused conversation.
Talk to Lava ↗