Introduction
A shared ERP creates value because Sales, Finance, Inventory, Purchase, HR and operations can work from one centralized database. That same centralization creates an important security challenge: employees should have access to the information required for their responsibilities without automatically gaining visibility into every confidential record in the organization.
In Odoo, departmental security should not be designed by simply hiding applications or menus. A secure implementation combines security groups, Access Control Lists, record rules, field-level restrictions and company or branch permissions. Odoo 19 identifies access rights and record rules as the primary data-driven mechanisms for controlling access and both are connected with users through security groups.
The objective is to implement the principle of least privilege without making collaboration difficult. Salespeople may need customer and quotation information but not payroll records. Warehouse employees may require delivery information but should not necessarily see confidential margins while Finance may require broader invoice visibility without needing unrestricted HR access.
Why Departmental Data Security Becomes Complex
A shared ERP contains information used by several departments at the same time. Customer information may be relevant to Sales, Helpdesk, Accounting and Delivery while employee information may be used by HR, payroll specialists and managers.
This means security cannot always be handled by assigning one application to one department. A user may need access to an application but only read permission on some records while another user may need create and edit rights only for records belonging to their own department.
A proper Odoo access policy should answer questions such as:
Which applications should the user access?
Which models can they read, create, edit or delete?
Which individual records should they see?
Which confidential fields should remain restricted?
Which companies or branches can they access?
Which actions require managerial approval?
Which information should remain inaccessible even through APIs or related records?
These requirements should be documented before custom access rules are developed.
Build Security Around User Roles
Odoo security groups should generally represent business responsibilities rather than individual employees. A user can belong to multiple groups and permissions associated with those groups combine to determine the user's effective access.
Typical groups may include Sales User, Sales Manager, Purchase User, Purchase Manager, Finance User, Warehouse Supervisor or Department Manager.
| Role | Main Access | Typical Restrictions |
|---|---|---|
| Sales Representative | Customer and sales activity | Payroll and accounting configuration |
| Sales Manager | Team sales and approvals | Sensitive HR information |
| Warehouse User | Receipts, transfers and deliveries | Financial reports and payroll |
| Purchase User | RFQs and purchase records | Unrelated sales and HR data |
| Finance User | Invoices, payments and reports | HR information not required by Finance |
| Department Manager | Department records and approvals | Other departments unless required |
| Executive | Cross-department reporting | Write access limited where possible |
The goal is not to give managers unrestricted administrator privileges. A manager should receive additional access only where their responsibilities require it.
Use ACLs for Model-Level Permissions
Access Control Lists or ACLs determine what operations users can perform on an Odoo model. Odoo supports four basic operations: Read, Write, Create and Unlink. If no applicable ACL grants an operation, the user cannot perform it.
For example, a department employee might receive read, create and write permission for a custom request model but no permission to delete records. A department manager could receive full access while an auditor might receive read-only access.
Odoo custom modules normally define these permissions inside security/ir.model.access.csv.
A simplified ACL could grant department users read, create and write access while keeping delete permission disabled. Department managers can then receive an additional ACL that grants the broader rights required for their role.
An important technical detail is that Odoo ACL permissions are additive. If Group A grants read access and Group B grants write access, a user belonging to both receives both permissions.
This is why assigning an additional group to solve one permission problem can accidentally provide broader access elsewhere.
ACLs Do Not Decide Which Records a User Can See
ACLs control access to an entire model. They do not determine which individual records inside that model should be visible.
Suppose a salesperson has read access to CRM opportunities. That permission alone does not necessarily mean the salesperson should see only their own opportunities or only records from their regional team.
The security layers should therefore be understood separately.
| Security Layer | What It Controls |
|---|---|
| Security Group | User role |
| ACL | Allowed operations on a model |
| Record Rule | Which individual records are accessible |
| Field Restriction | Which fields are accessible |
| Company / Branch Access | Organizational entity access |
Record rules provide the next level of protection.
Use Record Rules for Departmental Visibility
Odoo record rules restrict access to records according to a domain condition. They are evaluated after model-level access rights have been granted.
For a custom departmental model containing a department_id field, a rule can restrict users so they can access only records assigned to their department.
A department manager may then have another rule allowing access to all records belonging to the same department while executives or administrators can receive broader access where required.
Developers should not assume every standard Odoo model contains a department field. Sales records may be organized around sales teams, Inventory around warehouses, Projects around project membership and Accounting around companies.
Department-level security must therefore be designed around the actual ownership structure of each model.
Understand How Odoo Record Rules Combine
Record rules can become complicated when a user belongs to several groups.
Odoo distinguishes between global rules and group rules. Global rules intersect which means all applicable global conditions must be satisfied. Group rules combine differently and can expand access within the restrictions already imposed by global rules.
Several non-overlapping global rules can accidentally remove all access.
Developers should therefore avoid adding rule after rule simply until a screen starts working. The final effective security should be tested with the complete combination of groups assigned to real users.
Do Not Treat Hidden Menus as Security
Removing an Accounting menu from a warehouse user may improve usability but it does not secure the accounting records themselves.
Records may still be accessible indirectly through related records, URLs, APIs or other application features if the underlying permissions allow access.
The same principle applies to buttons and invisible fields. Hiding a button in the interface does not guarantee that the underlying operation cannot be executed by another method.
Real access control belongs in ACLs, record rules, field restrictions and protected backend business logic.
Restrict Sensitive Fields When Records Must Remain Shared
Sometimes a user needs access to a record but should not see every field within it.
Odoo supports restricting fields to selected groups. This is useful when several departments collaborate on the same record while certain financial or confidential values remain restricted.
Typical examples include:
Product cost information.
Confidential margins.
Salary or payroll values.
Internal risk ratings.
Executive approval comments.
Restricted financial data.
Sensitive custom fields.
For example, Sales may need to view products, descriptions and selling prices while cost information remains available only to selected finance or management groups.
Field restrictions should complement record security rather than replace it.
Do Not Add a Department Field Everywhere
A common customization mistake is adding department_id to every model simply because management wants departmental security.
The correct security dimension depends on the business process. A Sales opportunity may belong more naturally to a sales team while Inventory transactions may belong to warehouses or locations. Projects may use project membership while legal transactions belong to companies.
Before adding a custom department relationship, determine whether Odoo already has a suitable organizational structure.
Possible security boundaries include:
Using the existing business structure where practical reduces custom code and makes permissions easier to maintain.
Use Multi-Company Security for Legal Entities
Departmental security should not be confused with multi-company security.
Odoo allows administrators to define each user's Allowed Companies and Default Company. Company-specific transactions such as quotations, invoices and vendor bills are then handled according to the selected companies and applicable security rules.
Products and contacts can sometimes be shared across companies while transactions remain company-specific.
If Company A and Company B are legally separate organizations, company access should normally provide the main isolation layer instead of creating custom department rules to separate them.
Incorrect multi-company permissions can also create inconsistent behaviour so company access should be managed carefully.
Consider Branch Access for Operational Units
Odoo 19 supports branches as subdivisions of a parent company. User access can be granted at the parent-company level, branch level or both while branch-specific transaction visibility can be maintained.
Branches can be useful for organizations operating regional offices, stores or operational divisions under one legal company.
However, departments such as Finance, HR or Marketing are not automatically branches.
Use branches when the organization's operational structure genuinely matches the branch model. Use groups and record rules when the requirement is primarily about restricting departmental information inside the same organizational entity.
Follow the Least Privilege Principle
The safest security model gives users only the access they genuinely need to perform their responsibilities.
Instead of giving broad access and attempting to remove permissions later, administrators should begin with a controlled role and expand it when a documented business requirement exists.
A least-privilege review should consider:
Required applications.
Required models.
Read versus write access.
Whether deletion is necessary.
Department or team scope.
Company and branch scope.
Confidential fields.
Approval responsibilities.
This approach reduces unnecessary exposure while keeping each employee's Odoo workspace focused on their actual responsibilities.
Separate Transaction Entry From Approval Rights
Access control is not only about visibility.
A user who creates a purchase request may not need permission to approve it. A salesperson may prepare a quotation but require management approval before applying an exceptional discount.
Separating operational permissions from approval authority creates stronger internal governance.
Department employees may be allowed to create records, update draft transactions and submit requests for approval. Managers can then receive additional permissions for approval, rejection, confirmation, cancellation or controlled overrides.
Critical approval rules should always be enforced through backend logic rather than relying only on hidden or visible buttons.
Be Careful With sudo() in Custom Odoo Modules
Custom code can accidentally bypass an otherwise well-designed security structure.
One common development mistake is using sudo() whenever code encounters an access error. Elevated execution can solve the immediate technical problem but it may also allow operations that normal users should not be permitted to perform.
Developers should first understand why access was blocked.
If privileged execution is genuinely required, it should be limited to the smallest possible operation and should not return unrestricted records to a user who would normally be prohibited from accessing them.
The rule should never become:
Access Error = Add sudo()
Access errors often indicate that the security model or business requirement needs to be reviewed.
Avoid Bypassing the Odoo ORM
Direct SQL should not become a shortcut around Odoo security.
Custom applications should use supported Odoo models and ORM methods wherever practical. This preserves model security, record rules, computed logic and other framework behaviour.
Direct database manipulation can bypass normal Odoo controls and make the application's behaviour harder to maintain.
SQL may still be appropriate for carefully controlled technical requirements but it should not be used to avoid properly designed access rights.
Secure API and Integration Users
Machine users should follow the same least-privilege principles as employees.
A logistics integration may need delivery information but should not have access to payroll. A CRM connector may need Contacts and Opportunities while having no reason to modify Accounting configuration.
| Integration | Required Access | Unnecessary Access |
|---|---|---|
| Logistics Connector | Deliveries and tracking | Payroll |
| CRM Connector | Contacts and opportunities | Inventory valuation |
| Payment Integration | Required payment records | HR data |
| Reporting Integration | Selected read-only data | Create/delete permissions |
Avoid using Administrator credentials simply because they make API development easier.
Dedicated integration users make access easier to audit and reduce the impact of compromised credentials.
Test Access Using Real User Personas
Security configuration should be tested with realistic users.
Useful test accounts may include:
Department Employee.
Department Manager.
Sales User.
Finance User.
Warehouse User.
Multi-Company Manager.
Branch User.
Portal User.
Integration User.
Testing only as Administrator is not sufficient because administrators bypass or receive broader permissions than normal employees.
For every persona, test both what the user can do and what they must not be able to do.
A Sales user successfully opening their own quotation is only half of the test. The same user should also be tested against confidential accounting records, another department's restricted transactions and actions they are not authorized to perform.
Automate Security Tests for Custom Modules
Business-critical security rules should also be protected by automated regression tests.
A custom module can create records belonging to different departments then execute operations as different users to verify whether permissions are working correctly.
Useful automated scenarios include:
Employee cannot read another department's confidential record.
Manager can access records for the department they manage.
User cannot delete protected transactions.
Restricted fields remain inaccessible.
Company A user cannot modify Company B transactions.
Integration user cannot access unrelated models.
Employee cannot execute manager-only approval actions.
These tests become particularly valuable during Odoo upgrades or module refactoring because changes to groups and record rules can alter effective permissions unexpectedly.
Review User Permissions Regularly
A secure system can become insecure over time even when no technical changes have been made.
Employees change departments, managers receive temporary access and troubleshooting may require additional permissions. If those rights are never reviewed, users gradually accumulate access they no longer need.
Permission reviews should happen after:
Employee transfers.
Promotions.
Department restructuring.
Project completion.
Company or branch creation.
New module implementation.
Integration changes.
Employee departure.
Security incidents.
Access governance should therefore be an ongoing administrative responsibility rather than a one-time implementation task.
Maintain a Permission Matrix
Security becomes difficult to manage when the only documentation exists inside XML files or database configuration.
A permission matrix gives business and technical teams one readable reference showing who should have access to which information.
| Permission | Department User | Department Manager | Executive |
|---|---|---|---|
| View department records | Yes | Yes | Yes |
| View other departments | No | Selected | Yes |
| Create records | Yes | Yes | As required |
| Edit department records | Yes | Yes | As required |
| Delete records | Limited | Controlled | Controlled |
| Approve transactions | No | Yes | Selected |
| View confidential fields | No | Selected | Yes |
| Cross-company access | No | If required | If required |
This matrix should be reviewed whenever job responsibilities or business processes change.
Monitor Access Design as the ERP Expands
Access rights that worked when the company had 30 users may become difficult to manage after the organization grows to several hundred employees.
New departments, branches, companies, custom applications and integrations create additional permission combinations.
Administrators should periodically review whether the security architecture still matches the business structure.
Useful indicators include the number of custom security groups, overlapping roles, users with Administrator access, custom record rules, integration users and exceptions manually assigned to individual employees.
Too many exceptions often indicate that the underlying role design needs to be simplified.
How BrowseInfo Can Help With Advanced Odoo Access Control
BrowseInfo can help businesses design Odoo security around actual departmental responsibilities instead of using generic application-level permissions.
An advanced security implementation can include:
User-role assessment.
Security group design.
ACL configuration.
Department-level record rules.
Field-level restrictions.
Multi-company permissions.
Branch security.
Approval authority.
Portal permissions.
Integration-user security.
Custom security modules.
Automated permission testing.
Security documentation.
For heavily customized Odoo environments, existing rules can also be audited to identify excessive permissions, conflicting rules and custom modules that bypass standard security mechanisms.
The objective should be to protect sensitive information without blocking legitimate collaboration between Sales, Finance, Inventory, Purchase and other departments.
Common Odoo Access Rights Mistakes
One common mistake is hiding menus and assuming the underlying information is secure. Menu visibility improves usability but does not replace ACLs and record rules.
Another mistake is assigning broader groups whenever users report an access error. Because access permissions are additive, adding another group can unexpectedly open unrelated models.
Other common mistakes include:
Missing record rules.
Overly restrictive global rules.
Excessive Administrator access.
Uncontrolled sudo() usage.
Incorrect multi-company configuration.
Hard-coded department assumptions.
No testing of forbidden operations.
Old permissions remaining after role changes.
Integration accounts with unnecessary access.
A strong security model should remain understandable enough that administrators can explain why each role has each permission.
Frequently Asked Questions
1. What are access rights in Odoo?
Odoo access rights are model-level permissions that determine whether users can read, create, write or delete records. These permissions are normally assigned through security groups.
2. What is the difference between ACLs and record rules?
ACLs determine which operations users may perform on an Odoo model. Record rules determine which specific records inside that model users are allowed to access.
3. Can Odoo restrict users to their own department?
Yes. Where the relevant model contains an appropriate department or ownership field, record rules can restrict users to records belonging to their own department. The exact design depends on the model.
4. Can Odoo hide confidential fields from selected users?
Yes. Odoo supports group-based field restrictions which can make selected fields available only to authorized user groups.
5. Is hiding an Odoo menu enough to protect data?
No. Menu visibility is not a substitute for data security. Proper ACLs, record rules and field restrictions are required to secure the underlying information.
6. How does multi-company access work in Odoo?
Administrators configure the companies each user is allowed to access along with their default company. Company-specific transactions are then controlled according to that company context and the user's permissions.
7. Should developers use sudo() to solve access errors?
Not as a general solution. sudo() can bypass normal security rules. Developers should identify why access is blocked and use elevated execution only when a narrowly defined business requirement justifies it.
8. How should departmental access rights be tested?
Test permissions using real role-based accounts rather than only Administrator users. Verify allowed operations as well as attempts to access records, fields, companies and actions that the user should not be able to use.
Conclusion
Advanced Odoo security is not achieved by giving employees access to selected applications and hiding everything else from the menu.
A secure shared ERP combines security groups, ACLs, record rules, field restrictions and organizational access controls according to actual job responsibilities. Model-level permissions and record-level visibility should remain separate so organizations can share one ERP database without making every record universally accessible.
The correct security boundary must also reflect the real business structure. A department, sales team, warehouse, project, branch and legal company represent different concepts and should not automatically use the same access rule.
The strongest implementations apply least privilege, separate transaction entry from approval authority and regularly review user permissions. Custom developers must preserve those controls instead of bypassing them through excessive sudo() calls or direct database manipulation.
Security should also be tested continuously. Department employees must be able to perform their daily responsibilities while attempts to access unrelated confidential data should fail consistently.
When Odoo security groups, access rights, record rules, field-level permissions, multi-company controls and departmental governance are designed together, organizations can maintain the advantages of a centralized ERP while keeping sensitive departmental information available only to the people who genuinely need it.
