Who can see what in Odoo? Lock it down right

Open your Odoo and ask one question: can a junior salesperson see every colleague deals, the cost price on every product, and the payroll figures in HR? In a surprising number of live systems the answer is yes, because access was never actually configured - everyone landed in broad groups and no one narrowed it down. That is not a setup, it is a standing risk: a leak, an accidental edit, or a departing employee walking out with the full customer list. The good news is that Odoo has a genuinely capable permission system. The catch is that it has two layers people constantly mix up, and locking things down without breaking daily work means understanding both.

The two layers: access rights vs record rules

Almost every Odoo permissions mistake comes from not separating these two ideas, so start here. Access rights operate at the model level - they decide whether a group of users can read, create, edit, or delete a whole type of record: can this group touch invoices at all, can they only read products or also change them. Record rules operate at the row level - within a model the group can access, they decide which specific records that group actually sees: only their own leads, only their own warehouse documents, only their own company data. Access rights are the door to the room; record rules decide which drawers in that room you can open. You need both. Access rights alone give you all-or-nothing; record rules are what let a salesperson use the leads screen while seeing only their own leads.

Groups are how you keep it manageable

The rule that keeps Odoo security sane: assign permissions to groups, and people to groups - never permissions directly to a person. A group represents a role - salesperson, sales manager, accountant, warehouse operator - and carries the access rights and record rules for that role. When someone joins, you drop them into the right groups and they inherit everything; when they change roles, you move them; when you need to tighten a permission, you change it in one place and everyone in the role updates. Odoo also layers groups, so a manager group typically includes the user group and adds to it. Design the roles first - list who does what and what each honestly needs to see - and the technical configuration falls out of it. Skip that design step and you end up with everyone in Administrator because it was easier, which is exactly the risk you were trying to avoid. This role mapping is a core part of how we run an Odoo implementation, precisely because it is so often skipped.

The mistake almost everyone makes

Here is the trap: teams configure access rights, see that a salesperson can open the CRM, and assume they are done - so every salesperson sees every salesperson leads and pipeline. The access right let them into the leads model; nothing restricted which leads. The fix is a record rule that scopes the model to "records where the salesperson is me" (or "my team" for a manager). The same pattern applies across the system: an accountant who should see only one company in a multi-company group, a warehouse user who should see only their location documents, a portal user who should see only their own orders. Whenever a role can access a model but should not see all of it, the missing piece is a record rule, not another access right. Multi-company setups make this sharper still - the boundaries there are related to the ones we cover in running a clean go-live where reports reconcile, because bad data visibility and bad data hygiene tend to travel together.

Field-level and a sane rollout

Sometimes a whole record is fine but one field is sensitive - a cost price on a product a salesperson quotes from, a salary on an employee record their manager can otherwise see. Odoo can restrict individual fields to specific groups, so the record stays usable while the sensitive value is hidden from those who should not see it. Use this sparingly and deliberately; it is powerful but easy to over-engineer. As for rolling any of this out: change permissions in a test database first, log in as a real user of each role and click through their actual daily work, and confirm they can do their job and cannot see what they should not. Tightening security in production without testing is how you accidentally lock the accounts team out of invoices on month-end. Where the design gets genuinely complex - overlapping roles, multi-company, external portal access - it is worth an expert review, which is part of what our Odoo consulting engagements exist to do.

Frequently asked questions

What is the difference between an access right and a record rule?

An access right works at the model level: it decides whether a group can read, create, edit, or delete a type of record at all - invoices, leads, products. A record rule works at the row level: within a model the group can access, it decides which specific records they see, such as only their own leads. Access rights open the door to a data type; record rules decide which of those records are visible. You almost always need both.

Should I ever assign permissions directly to a user?

No. Always assign permissions to groups and add users to those groups. Direct per-user permissions become impossible to audit and maintain - within a year no one knows who can see what or why. Groups map to roles, roles carry the permissions, and people inherit them by membership. When a permission needs to change, you change it once on the group and everyone in that role updates together.

Why can a user still see records they should not, even after I set access rights?

Because access rights only control whether they can open the model, not which records within it they see. If a salesperson sees every rep leads, the access right let them into the leads model and there is no record rule scoping it to their own. Add a record rule that limits the group to the relevant records - their own, their team, their company - and the over-broad visibility closes without removing their ability to use the screen.

Can I hide a single field like cost or salary?

Yes. Odoo supports field-level restrictions so a specific field is visible only to chosen groups, while the rest of the record stays usable for everyone else. It is the right tool when the whole record is fine to see but one value is sensitive - product cost, employee salary. Use it deliberately rather than everywhere, and test it as a real user of each role so you confirm the field is hidden where it should be and present where it is needed.

The short version: Odoo can lock data down precisely, but only if you use both layers. Design roles as groups, set access rights to control which models each role touches, add record rules to control which rows they see, and restrict the odd sensitive field where needed. Test every role in a sandbox before you go live, and the result is an Odoo where everyone can do their job and no one can see what they should not.