Build an Odoo Roles and Approval Matrix for Operational Control

Build the matrix around consequential workflow decisions, not menus or job titles. For each business role, record who may initiate, amend, approve, execute, reverse and administer an action. Add the relevant company, warehouse and record scope; any approval condition; conflicting duties; enforcement method; and review responsibility.

Then test the combined access held by representative users across complete transactions. A purchasing officer who cannot approve their own purchase order may still present a control problem if they can change supplier details, confirm receipt and influence another stage of payment processing.

This approach reflects established least-privilege and segregation-of-duties principles. It also matches Odoo's security model, in which model-level access rights, record rules, field restrictions and inherited group permissions can combine to determine what a user can actually do.[1][4][5] The matrix documents the intended control; testing confirms whether the installed Odoo configuration delivers it.

Build the matrix at decision level, not menu level

A useful matrix describes business actions precisely enough for a process owner to approve and an Odoo administrator to configure. "Warehouse access" is too broad. Receiving stock, validating transfers, entering inventory adjustments, approving write-offs and changing warehouse configuration have different consequences and should be considered separately.

For every controlled action, capture:

• Business process and action. Use terms operators recognise, such as releasing a purchase order, validating a delivery, entering a stock adjustment, issuing a credit note or exporting customer data.
• Business role. Identify the role that needs the action rather than copying a person's job title.
• Permission required. Distinguish viewing, initiating, editing, approving, executing or posting, reversing, deleting and administering.
• Record scope. State whether access applies to the user's records, a team, a company, a warehouse, a location or the entire database.
• Approval condition. Record the value, risk condition or exception that requires another person's authorisation.
• Conflicting duties. Identify actions that should not sit with the same person or role.
• Enforcement method. State whether the control is enforced in Odoo, through an approved integration or customisation, or through a documented manual procedure.
• Exception route. Document temporary cover, urgent processing and escalation arrangements, including expiry.
• Evidence. Specify what demonstrates that the control operated: an approval record, change history, exception review or access report.
• Accountability and review. Record which process or data owner confirms the design and how often it is reconsidered.

This level of detail matters because Odoo access rights operate at the model level and commonly control create, read, write and delete or unlink operations. Record rules can further restrict which records a user can access, while field access can restrict particular fields to specified groups.[1] Those technical layers do not automatically express every business distinction in plain operational terms.

For example, the matrix may state that an order-management role can prepare a customer return but cannot authorise a refund above a defined amount. Whether that distinction is available through standard configuration in the relevant Odoo release must be verified. Do not mark a control as implemented merely because the user can open the correct app.

If the matrix is being created during an Odoo implementation support, agree on its scope before user accounts are configured. Otherwise, early convenience-based access can become the undocumented baseline that later testing has to unwind.

Define business roles before assigning Odoo groups

Start with a role catalogue based on stable responsibilities. Job titles are unreliable access-control units: two warehouse managers may oversee different sites, a finance lead may only cover one company, and a senior operator may need approval authority without system-administration rights.

An inventory-heavy ecommerce business might need roles such as:

• order-management operator;
• customer return reviewer;
• warehouse receiver;
• dispatch operator;
• inventory controller;
• purchasing preparer;
• purchasing approver;
• finance preparer;
• finance reviewer or poster;
• reporting analyst;
• product or supplier master-data steward;
• integration identity, where one is used; and
• Odoo security administrator.

These are design examples, not prescribed Odoo group names. Each role should be justified by actual work, then mapped to the appropriate Odoo groups and record scope. Odoo groups can inherit other groups, so effective permission may be broader than the label visible to a business reviewer suggests.[1][2]

Three distinctions deserve particular attention.

First, separate operational authority from technical administration. A person may be accountable for approving high-value stock adjustments without needing the ability to alter security groups, company configuration or approval settings. Conversely, the administrator implementing access should not become the default business approver simply because they can change the configuration. This follows the least-privilege principle: users and privileged accounts should receive only the access needed for authorised tasks.[4][5]

Second, define scope as carefully as capability. In a multi-warehouse Odoo operating model, the same warehouse role may require different access by company, site, stock location or operating team. Test that a user can process the intended warehouse without viewing or changing unrelated records. Multi-company and record-rule behaviour should be verified with the actual configuration rather than inferred from role names.[1]

Third, treat non-human and exceptional access as part of the matrix. Include integration identities, temporary contractor access, cover for absent approvers and emergency administration. Record the business purpose, permitted actions, accountable sponsor and expiry condition. An access matrix that covers permanent employees but ignores integrations and temporary privilege does not describe the complete control environment.[4][5]

Make approval thresholds explicit and resistant to bypass

An approval threshold is a business rule, not simply a number attached to a manager. It must define what triggers approval, who may approve, what happens after rejection or amendment, and how exceptions are handled.

Odoo documents amount-based purchase order approval as a supported pattern within the Purchase application.[3] That provides a useful example of native threshold control in a specific workflow, but it should not be treated as proof that every sales, stock, finance or refund process has an equivalent standard setting. Confirm the available control against the installed Odoo version, edition, applications, company configuration and approved customisations.

For every threshold, document these conditions:

• the transaction or action being controlled;
• the amount, quantity, percentage or risk event that triggers review;
• whether the boundary applies below, at or above the stated value;
• the currency and exchange-rate treatment;
• whether tax, freight and other charges are included;
• whether related or split transactions are aggregated;
• the authorised approver and alternate;
• whether self-approval is prohibited;
• what happens if an approved transaction is edited;
• who may change the threshold itself; and
• how transactions created through imports or integrations are treated.

Not every high-risk decision is monetary. Supplier bank-detail changes, security-role changes, product-cost amendments, bulk data exports and warehouse-location configuration may warrant independent review regardless of transaction value. The matrix should therefore support both value-based and event-based approvals.

For an ecommerce and inventory operation, practical control decisions may include:

• purchase orders above a business-defined commitment level;
• sales discounts or manual price overrides outside approved policy;
• refunds, credits or cancellations above an agreed value;
• inventory adjustments involving high quantities, high-value stock or controlled locations;
• new suppliers or changes to sensitive supplier data;
• unusual journal entries or payment-related changes; and
• changes to user access, approval settings or integration credentials.

These are control-design prompts, not claims that Odoo enforces every example natively. Mark the enforcement method beside each one. If the requirement depends on a procedural review, say so plainly and identify the evidence that the review occurred.

Also design for the less convenient cases. Define what happens when the approver is absent, an order becomes urgent, a transaction is resubmitted after rejection or a value is reduced below the threshold after initially exceeding it. Without a documented exception route, staff may create informal workarounds that leave weak or inconsistent evidence. Risk-based control design and documented authorisation are consistent with ISO access-control guidance and the COSO control-activities principles.[5][6]

Prove segregation of duties with end-to-end transaction tests

Segregation of duties cannot be confirmed by reviewing one permission at a time. It must be tested across the full transaction and across all the roles held by a person. NIST defines separation of duties as dividing responsibilities to reduce the risk of harmful activity without collusion, while ISO/IEC 27002 calls for conflicting duties and areas of responsibility to be segregated.[4][5]

Use representative, non-administrator accounts in an appropriate non-production environment. For each role, run positive tests to confirm legitimate work is possible and negative tests to confirm prohibited actions are blocked or sent for the required review.

At minimum, test four operational scenarios.

1. Purchase to payment. Test supplier creation or amendment, purchase preparation, approval, goods receipt, bill handling and payment-related processing. Check whether one ordinary user can control too many consequential stages.
2. Order to refund. Test order entry, price or discount changes, fulfilment, cancellation, return processing, credit creation and refund authorisation. Include an order immediately below, exactly at and above any threshold.
3. Inventory movement and correction. Test receiving, internal transfers, dispatch, stock adjustments, scrap or write-off handling, and reversal. Confirm that company, warehouse and location restrictions remain effective throughout the process.
4. Administration, integrations and reporting. Test user-role changes, threshold changes, data imports, integration activity, exports and correction procedures. A transaction blocked in the user interface should not be assumed controlled until relevant alternative routes have also been considered.

   Apply the same test pattern to each scenario:

   • confirm the role can perform its intended action;
   • confirm it cannot perform the conflicting action;
   • test all combinations of roles assigned to the user;
   • test the correct company, warehouse and record scope;
   • test the approval boundary and rejection path;
   • amend the transaction after approval and observe what happens;
   • test reversal or cancellation;
   • include integration-created transactions where relevant; and
   • retain the test result and remediation decision.

   A failure is not limited to an explicit "access granted" result. Treat the control as ineffective if a user can approve their own high-risk transaction, alter the rule that governs their approval, gain broader access through another inherited group, reach unrelated company or warehouse records, or complete the same outcome through an untested route.

   Odoo's own security documentation explains that access rights and record rules interact, with group relationships contributing to effective access.[1] That is why role testing should use realistic user profiles rather than an administrator account or an isolated permission review.

   If full preventive separation is impractical in a small team, do not remove the conflict from the matrix. Record the residual risk and establish a compensating control, such as independent review of exception activity and supporting evidence by someone who did not process the transaction. The reviewer, timing and retained evidence must be explicit. This follows the broader control principle that identified risks require appropriately designed and operating control activities.[6]

   Repeat these tests when access is rebuilt during an Odoo migration planning. Migration can change group assignments, record scope, integrations and custom behaviour even when role names remain familiar.

Keep the matrix current through accountable review and retained evidence

Access becomes unreliable when the documented role and the user's actual responsibilities drift apart. ISO/IEC 27002 calls for access rights to be reviewed at planned intervals and after changes, while NIST account-management guidance covers the creation, modification, review and removal of accounts and privileges.[4][5]

Set a review cadence based on consequence rather than applying one arbitrary interval to every role. Privileged administration, finance, sensitive master data and high-impact inventory actions generally warrant closer scrutiny than low-risk read-only access. The organisation should document the interval it has chosen and why it is proportionate.

Do not wait for the next scheduled review after a material change. Reassess access when:

• a person joins, changes role or leaves;
• temporary cover or contractor access expires;
• a new company, warehouse or location is introduced;
• an Odoo application, integration or customisation changes;
• approval limits or financial authorities change;
• a migration or major configuration release occurs;
• a control test fails; or
• an operational incident reveals unexpected access.

Responsibility should remain distributed. Process owners confirm which actions a role needs. Data owners confirm record scope, sensitive fields and export rights. Finance owners approve financial thresholds. Line managers confirm current business need. Odoo administrators implement approved changes and provide configuration evidence. Security, risk or internal-audit personnel can challenge unresolved conflicts and exceptions. No single technical role should silently make every business decision about access.[4][5]

Retain enough evidence to reconstruct the decision:

• the approved matrix version;
• current user-to-role assignments;
• recorded business approvals;
• temporary-access expiry details;
• unresolved conflicts and accepted residual risks;
• test scripts and results;
• changes made after testing; and
• the date and outcome of the latest review.

Practical sequencing is straightforward: document the critical workflows, define the role catalogue, agree on approval policy, configure access, run transaction-level tests, remove superseded permissions, and begin ongoing monitoring. Dependencies such as multi-company scope, integrations, custom modules and migration work should be identified before testing begins.

Where governance continues after launch, an Odoo support arrangement should distinguish routine user administration from changes that alter control design. The LatestBuy case study also provides relevant context for Syceed's work in an inventory-heavy ecommerce environment.

Source basis and Odoo version caveat

1. Odoo S.A., Odoo 19.0 Developer Documentation - Security in Odoo, covering access rights, record rules, field access, group relationships and security pitfalls.
2. Odoo S.A., Odoo 19.0 Documentation - Users and Access Rights.
3. Odoo S.A., Odoo 19.0 Documentation - Purchase Order Approval.
4. National Institute of Standards and Technology, SP 800-53 Revision 5, particularly AC-2 Account Management, AC-5 Separation of Duties, AC-6 Least Privilege, AU-2 Event Logging and AU-6 Audit Record Review, Analysis and Reporting.
5. ISO/IEC 27002:2022, particularly controls 5.3 Segregation of Duties, 5.15 Access Control, 5.18 Access Rights and 8.2 Privileged Access Rights.
6. Committee of Sponsoring Organizations of the Treadway Commission, Internal Control-Integrated Framework (2013), particularly the control-activities principles.

Odoo features and configuration options can vary by release, edition, installed applications and customisation. Validate the final matrix against the documentation for the deployed version and test the resulting access in the business's own operating context.

If the exercise has exposed a more basic question about how the platform's applications, data and operating model fit together, start with Syceed's guide to what Odoo is.

About the author

Shaun Campbell - Project Director, Syceed

Shaun Campbell is Project Director at Syceed and an Australian ecommerce operator with practical experience across online retail, Odoo implementation, migration planning, inventory workflows and operational systems cleanup.

LinkedIn profile