Access rights are one of the last things configured in most Odoo implementations and one of the first things to cause trouble after go-live. During the build, it is easier to give everyone administrator access and sort it out later. Later rarely comes, and a year on, a sales rep can still edit the chart of accounts and nobody can say who changed a vendor's bank details.
Getting roles right is not difficult, but it has to be designed rather than accumulated. This is how we approach it.
How Odoo access actually works
A few building blocks do most of the work:
- Access levels per app. On each user's record, every installed app offers a short list of levels. Sales, for example, distinguishes users who see only their own documents, users who see all documents, and administrators.
- Record rules. Behind those levels, rules decide which records a user can see within a model: their own quotations, their team's, or everything in the companies they are allowed to access.
- Restricted menus, buttons and fields. Some screens and actions only appear for certain groups, so two users on the same form may see different things.
- Allowed companies. In a multi-company database, each user is granted one or more companies, and record rules keep the rest out of view.
One property matters more than the rest: in Odoo, rights add up. A user receives everything granted by every group they belong to, and there is no group that takes a right away. If someone was made an Inventory administrator for a one-off task, adding them to a more limited group later does not undo it. You have to remove the higher level itself.
The mistakes we see most often
- Everyone is an administrator. It starts during configuration, when consultants and key users need to move quickly, and is never reversed. Settings administrators can change configuration and other users' rights, so this is the single biggest risk on the list.
- "Give her the same access as him." Copying a person instead of a role means every new hire inherits the history of whoever they were copied from, including rights granted for a project that ended long ago.
- Shared logins. When three warehouse staff use one account, the chatter on every record shows the same name, and the history stops telling you who did what.
- Testing as admin. If user acceptance testing is run with administrator accounts, access errors stay hidden until real users log in on go-live day, which is the worst possible moment to find them.
- Leavers who keep access. Accounts of people who have left should be archived on their last day, not when someone notices months later.
Start from job roles, not people
The practical tool is a role matrix: a simple table with job roles down one side and Odoo apps across the top. In each cell, choose one of four answers: no access, own records, all records, or administrator. Typical roles are sales rep, sales manager, purchasing officer, warehouse operator, accountant and finance manager, but use the roles your organization actually has.
Then add a second layer for the sensitive actions in your business, the ones an auditor or a finance director would ask about:
- Who can confirm a sale or purchase above a certain value?
- Who can post journal entries, and who can reset them to draft?
- Who can create a vendor or change their bank account?
- Who can validate inventory adjustments?
- Who can see costs and margins?
- Who can delete records or export large lists?
Assign each person to one role, or to a small, deliberate combination of roles. When someone changes jobs, you change their role rather than patching their rights.
Segregation of duties: where standard stops
The classic finance control is that the person who creates a vendor and their bank details should not also be the person who approves and pays that vendor's bills. Odoo's standard access levels are deliberately broad, and on their own they will not enforce every separation of this kind. Some controls exist out of the box, such as an optional manager approval for purchase orders above an amount you set. Others do not.
For each gap, you have three honest options: accept the risk and add a review step, such as a weekly check of changed bank accounts; split the work between people and rely on procedure; or customize the access model. Customization is legitimate, but custom groups and rules are code. They need a clear specification, testing as the affected users, and care at every version upgrade.
Test permissions like any other feature
Create one test user per role before UAT starts, and run every test script logged in as the role that will do the work in real life. A purchasing officer's script is run as a purchasing officer. When something fails with an access error, decide whether the role is wrong or the script is, and fix it then, not on go-live morning. It also helps to set Odoo's default access rights for new users to the most limited sensible level, so a new account starts closed rather than open.
Keep it maintained
Roles drift. Review the matrix against the actual user list every six months and whenever the organization changes shape, and keep administrator access to two or three named people. If your Odoo is already live and nobody can say with confidence who can do what, our ERP health check looks at how the system is really configured and used, and the access model is a sensible place to start.