Every Odoo implementation eventually hits the same wall. You've on boarded a client user, an external consultant, or a new hire in sales, and now they can see fields, buttons, or entire tabs they have no business touching product costs, internal margins, vendor pricing, or a "Confirm" button that skips a step your process depends on.
If you've tried to hide a field in Odoo for specific users, you've probably found that native access groups can't do it, they control whether someone opens a model at all, not what they see inside a form they're already allowed into. The usual fallback is custom view inheritance, a developer, a support ticket, and a wait. For a business trying to move fast without a bench of Odoo developers on call, that's not sustainable. Getting real Odoo field level security without writing code requires a different kind of tool.
What Is Field-Level Access Control in Odoo?
Odoo's native access groups and record rules operate at the model and record level they decide whether a user can open a Sales Order at all, or which Sales Orders they're allowed to see. They don't decide what that user sees inside the form once they're in it.
Field-level access control fills that gap. It lets an admin restrict individual fields, buttons, tabs, and menu items for specific users or groups so two people looking at the same Sales Order can see genuinely different forms, without any changes to the underlying view or model. Creyox Technologies built the Access Management Studio module specifically to make this configurable without code.
Key Features
- Field, button, menu, and tab-level restrictions — make a field read only based on user group (hide the Cost field and margin column on Sales Order lines for anyone outside the Finance group, while leaving the rest of the form untouched).
- Conditional rules based on record state — restrict an action only when a record is in a certain state (make a Purchase Order read-only once it moves into the "Approved" state, so downstream edits require a formal reversal instead of a quiet change).
- Domain-filtered create/update/delete restrictions — limit who can create, edit, or delete records using domain conditions, not just blanket on/off permissions.
- Developer mode restrictions — disable developer mode for users who don't need configuration-level access, reducing the risk of accidental misconfiguration.
- Login restrictions — disable or limit login access per user without deactivating their account entirely.
- Import/export blocking — stop specific users from exporting sensitive data sets or bulk-importing records that should only move through the UI.
- Multi-company rule isolation — set up Odoo multi-company access rules so a restriction configured for one entity doesn't leak into another in the same database.
How It Works
Setting up a rule follows a straightforward pattern rather than a technical build. An admin picks the target of a specific user, a group, or a company then chooses what to restrict: a field, a button, a menu item, or an action like create or export. From there, they define the condition, if any (always-on, or only when a record is in a particular state), and activate the rule.
There's no view inheritance to write, no XML to touch, and no need to involve a developer for routine changes. Rules can be adjusted or deactivated the same way they were created, which matters when a client's org structure or approval process changes six months after go-live.
Use Cases
Hiding financial data from non-finance staff. A sales team needs full access to Sales Orders to do their job, but showing them landed cost and margin invites pricing decisions that aren't theirs to make. Restricting the Cost field to the Finance group keeps the rest of the order fully usable.
Giving external consultants read-only access. A client brings in an outside consultant who needs to review project records but shouldn't be able to edit or delete anything. A read-only rule scoped to that user's login solves this without building a separate portal.
Disabling developer mode for non-technical users. An office manager with admin rights doesn't need and shouldn't have access to technical settings and debug tools. Restricting developer mode removes that risk without touching their functional permissions.
Restricting actions on locked or draft records. A Purchase Order shouldn't be editable after approval, but Odoo's default groups don't distinguish between a draft and an approved record. A state-based rule locks specific fields the moment the record crosses into "Approved," while still allowing draft edits.
Why This Matters for Odoo Security
Most Odoo access problems aren't caused by malicious actors they're caused by users who simply have more permissions than their role requires, because granting broad model-level access was faster than configuring anything finer. That gap creates two kinds of risk: accidental edits by people who shouldn't be touching sensitive workflow steps, and unnecessary exposure of data like margins, vendor terms, or internal notes to people who don't need to see them.
Good Odoo permission management means permissioning at the field and action level instead of settling for all-or-nothing model access. Fine-grained, no-code control doesn't just tighten security on paper, it removes the daily friction that leads admins to over-permission users in the first place because locking things down properly used to mean a development ticket.
Getting Started
Getting set up starts with assigning access management rights to an admin user, who then creates and activates rules from directly inside Odoo no separate tooling required. From there, rules can be layered gradually: start with the highest-risk fields and actions, then expand coverage as needed.
You can explore the Access Management Studio module on the Odoo Apps Store or visit creyox.com for details. If your setup involves multiple companies, external users, or workflows that need state-based restrictions, it's worth looking at as well, or reaching out to Creyox Technologies directly for a walk-through.