A practical question before any setup: two employees in sales — does each of them see every customer?
The answer is set by role, need and action, not by one rule for everyone. In an illustrative example, a sales rep sees their own customers, a sales manager sees the team’s customers, and an accountant reads invoices without editing sales orders. Financial approval rights are separate: whoever creates a quotation does not automatically approve the discount or payment.
The outcome we want: a manager who knows who sees what and why, a finance team that can trace approvals without ambiguity, and a team that works through the day knowing when they can complete a task and when an additional permission needs approval.
At ToDoOps, we agree roles and record scope with process owners, configure the system, train the team and test accounts that represent their work. Odoo combines access rights on record types with rules controlling which records a user can reach. Financial approval is a separate business decision to configure in the workflow 1.
Odoo access for sales and finance: what should change?
An owner asks, “Can a sales rep see all our invoices?” The finance manager asks the opposite: “Can I review invoices without every employee seeing company-wide data?” The answers differ, and neither holds until you agree on the role and the process first. A reasonable goal: sales follows its own opportunities, and finance reviews invoices, without exposing all company data to everyone. Treat those roles as a defined configuration you will test, not an assumption.
Odoo access rights, record rules and approvals
1. Model access. This sets CRUD operations on a record type and is granted through groups. Group rights are additive: a user in two groups gets the combined rights of both 1.
2. Record rules. These apply to records after model access. If the model permission is granted and no record rule applies to that user, operation and model, access is allowed within those model permissions, as the documentation describes 1. So do not assume that a missing rule means restriction.
3. Approval. Permission to edit a record is not a financial approval policy. The person who can edit an invoice is not necessarily the person who approves it. Approval needs a clear workflow and testing with the role owners’ own accounts.
Practical notes:
- Roles can differ by app, and some cover “own documents” or “all documents” (Own Documents / All Documents) in certain apps, not all of them.
- An external portal user differs from an internal employee. We make no claims here about licenses or pricing.
- Hiding a menu is not proof of data permission; access may still exist through another path.
A role matrix you agree on
This matrix is a project target, not a product default. The roles are hypothetical, and the chosen record type, sales orders, is only there to show the idea:
On mobile, swipe the table horizontally if any columns are out of view.
| Role | Read | Create | Edit | Delete |
|---|---|---|---|---|
| Sales | Own records only | Yes | Own records, before confirmation | No |
| Warehouse | Confirmed orders, for delivery | No | No | No |
| Finance | Yes | No | No | No |
Three roles × four operations = 12 test cells. For each cell where the test model fits, write one allow case and one deny case, which gives a proposed 24 test cases. That number is a suggested test count. It is not 24 security controls, and it is not an NCA requirement. If the model does not suit one of the two tests in a cell, record that rather than inventing a case.
For a hypothetical estimate of implementation cost, time, and savings, you can use our calculators. Use them to plan the implementation scope; the matrix here defines the work you will test.
Testing ground rules
- Use test data. Do not request full-export permissions, and keep personal data and real records out of testing.
- Test with the role owners’ own accounts, not only the administrator’s.
- Do it in an isolated copy with an approved administrator, because a wrong configuration can lock administration out.
A governance reference: the Essential Cybersecurity Controls
The National Cybersecurity Authority (NCA) publishes the Essential Cybersecurity Controls (ECC 2-2024), which offer useful principles for access governance on printed pages 19–20 (PDF pages 22–23): need-to-know and need-to-use, least privilege, and segregation of duties (2.2.3.3); privileged access management (2.2.3.4); and periodic review of identities and access rights (2.2.3.5) 2. We use it as a reference for structuring decisions. We do not assume it is mandatory for every Saudi company, or that Odoo settings alone amount to a ready-made compliance program.
The practical reading is simple: give each role what its work needs, separate who creates from who approves, keep administrative rights narrow, and review the list regularly.
Leavers and internal transfers
When someone leaves, or moves from sales to finance, review their rights under company policy. Because group rights are additive, moving them without removing the old group gives them the sum of both roles.
How teams react
A sales team may read narrower visibility as distrust. Explain that the aim is defining the work, not watching people, and set up a channel for requesting extra access that the process owner approves. Financial acceptance remains part of the approval workflow your management has tested.
Frequently asked questions
Is hiding the menu enough to protect data? No. It tidies the interface. Verification comes from model access, record rules, and testing the account itself 1.
Does edit permission mean financial approval? No. Approval is a separate workflow that you design and test with the role owners’ accounts.
What should change when someone moves to another department? Review old and new group memberships with the process owner, then test what the new role needs and which former access should end under company policy.
Next step
Bring the owner, the finance manager, the purchasing lead, and the warehouse lead together. Agree on the matrix, then turn it into test cases in an isolated copy. To see a sales and inventory flow with fictional data before the discussion, try the guided demo. It is not a permissions-configuration environment and does not simulate every app. Review Odoo apps and industries to scope what applies to your operation, and use the calculators for a hypothetical cost and time estimate. If you would like our team to get in touch, request it through the contact page. For an overview of the service, return to ToDoOps.
References
[1] Odoo — official19.0 documentation. Access rights and Security in Odoo, reviewed3November2026: model permissions, additive group rights, record rules, and portal/internal users.
[2] National Cybersecurity Authority — Essential Cybersecurity ControlsECC2-2024. Printed pages19–20 of the public English version, controls2.2.3.3–2.2.3.5: least privilege, segregation of duties, privileged access and periodic identity/access reviews.