Odoo Studio is the Enterprise tool for changing the system without writing code. An administrator can add fields to a form, rearrange a view, create a new report layout, define an automated action or even build a small new app. Clients are usually delighted by it, and rightly so. It is also the source of some of the most tangled systems we are asked to untangle. Both things are true, and the difference is in how it is used.
What Studio does well
Adding a field that the business needs to record and that Odoo does not have. A contract reference on a sales order, a preferred delivery slot on a customer, an internal classification on a product. These are the most common and the most sensible uses.
Adjusting views so that people see what matters. Hiding fields a department never uses, reordering a form to match the way a process runs, adding a filter or a grouping that saves a daily search.
Simple automations. Send an email when a stage changes. Set a field based on another. Create an activity when a record is created. Studio's automated actions cover a large share of what businesses ask for.
Report layouts. Adjusting the quotation or invoice template to match your branding and to include the fields your customers need.
Where it causes problems
Studio changes live in the database rather than in versioned code. That has consequences.
There is no test environment unless you create one deliberately. A change made in Studio on production is live immediately. On Odoo.sh you can work in a staging branch and copy the change; on Odoo Online there is a test database you can request. In practice many administrators make changes directly in production, and small mistakes reach users instantly.
There is no record of why a change was made. Six months later a field exists and nobody remembers who added it or what it was for. Fields multiply, forms grow, and the system becomes harder to use than the one it replaced.
Complex logic does not belong in Studio. Automations that chain together, calculations across several records, anything with conditions that need to be tested: these are code, and building them in Studio produces something that cannot be tested, reviewed or version controlled.
Upgrades carry Studio changes automatically in most cases, but changes built on fields or views that Odoo itself alters between versions can break, and finding out why is harder than with code.
The rules we apply
Before a change is made in Studio, we ask four questions. Is the change small and self contained: a field, a view adjustment, a simple action? Would a developer build it the same way, or is Studio being used to avoid a design conversation? Has it been tried in a staging or test database first? Is it written down: what was changed, by whom, why, and where the change is visible?
If the answer to all four is yes, Studio is the right tool and is faster and cheaper than development. If any answer is no, we either build the change as a proper module or we go back to the requirement and ask whether it is needed at all.
Keeping a Studio register
For every client on our managed service we maintain a register of Studio customisations: each field, view change, automation and report, with its purpose and date. It takes a few minutes per change and it is the document that makes the next upgrade a known quantity rather than an investigation. We recommend it to every Odoo administrator, whether they work with us or not.
In short
Use Studio for the small things, test them first, and write them down. Use code for the rest. If you are unsure which side of the line a change falls on, that is exactly the kind of question our support desk answers every week.
Frequently asked questions
What does the managed service include?
User support, maintenance including minor updates and bug fixes, configuration changes as the business changes, small developments, monitoring of integrations and scheduled actions, and training for new staff. Each request is logged with its resolution, and you receive a monthly summary of hours and outcomes.
What are your response times?
Response times are agreed in writing before the service begins and depend on the priority of the request and the service level you choose. Issues that stop the business are handled first, during working hours across the time zones we cover.
Can you support an Odoo system you did not implement?
Yes. Onboarding starts with a review of the configuration, custom modules, integrations and open issues, so that we know how the system was built before we take responsibility for it.
How do you handle upgrades under the managed service?
We keep custom code current with minor releases as part of maintenance, and we plan major version upgrades with you as a scoped project, usually every one to two years. Keeping current makes each upgrade smaller.
What happens to unused hours?
Unused hours in a monthly allowance can be carried into larger pieces of work within an agreed period, such as a new report, a new app or part of an upgrade.
