During an ERP acceptance meeting, a manager completes an operation successfully. A purchasing employee then signs in and can perform an action they should not control. This difference shows why a demonstration with one powerful account is insufficient: test the actual working roles and combinations of their permissions.
Begin with management's process decision
Before configuration, establish who prepares, reviews, approves and only reads. These decisions belong to the organization's process owners rather than a developer interpreting job titles. Two employees with the same title may need different permissions according to task, record or approved delegation.
Consider a fictional exhibition-supplies organization choosing to separate purchase-request preparation from approval. Its sample includes a warehouse clerk, buyer and supervisor, followed by a user combining two roles. This is an illustrative internal policy, not an accounting rule or universal compliance requirement.
Write expectations before viewing the screen
Have the process owner define allowed and denied results for specific actions on specific records. “Purchasing access” may conceal differences between reading, editing, approving and deleting a request. Define those actions in terms both users and provider understand without assuming every ERP implements them identically.
Agree on synthetic accounts, suitable data and an identified version and environment. An authorized specialist prepares the demonstration; a department owner need not share personal passwords or experiment on real production operations. Record unavailable cases so missing tests cannot be presented as successful ones.
A matrix management can approve
| Review case | Question | Recorded evidence |
|---|---|---|
| Single role | Can it perform the permitted action on the intended record? | Expectation, action and evidence |
| Prohibited action | Does it remain outside the role's permissions? | Denial without unauthorized change |
| Combined roles | Does the combination conflict with policy? | Actual groups and remediation decision |
| Exception | Who approves it, why and when is it reviewed? | Limits, owner and approval reference |
Add reviewers, dates and results after corrections. Acceptance must consider more than prohibited actions: an authorized user unable to perform their task also needs resolution. The matrix connects software behavior to management policy rather than simply counting configured roles.
A group name is not the account's whole access
Odoo 19 documents inherited group permissions and distinguishes model rights from record rules. Ask the provider to review the tested account's effective permissions rather than one visible configuration choice. An additional group may explain a result the department owner did not expect.
In the example, two separate duties can each allow reasonable actions, while combining them for one person conflicts with policy. Test the combination independently, then decide whether assignments, procedures or an explicit exception must change. Broad access should not silently become a shortcut for easier training.
Creating a separation rule is not verification
Dynamics 365 warns that creating a segregation-of-duties rule does not automatically verify existing roles and assignments; compliance must be checked after creation or modification. This is a documented product mechanism, but it prompts an important buyer question: where is evidence that the configured policy holds?
Do not assume Odoo or custom software provides the same mechanism. Ask the provider to distinguish supported behavior from additional administrative review or procedures. Give exceptions a reason, owner and review boundary instead of allowing them to persist without follow-up after an employee changes tasks.
Use the appropriate account and retain limits
Odoo describes a superuser mode bypassing access rights and record rules; this should not be confused with every administrator account. Ask which account and mode the demonstration used and request evidence matching everyday use. A hidden button alone also fails to explain other in-scope actions or saved-record effects.
Complement role-based training acceptance with this matrix and use the security-assessment procurement brief for broader work. Bring departmental policy, combinations and exceptions when discussing ERP implementation with Nextwave. A passing sample is neither security certification nor coverage of every possible permission.
Sources for these distinctions
Odoo 19 access rights and Dynamics segregation of duties were read on 4 November 2026 without modifying accounts. Prepared with AI assistance and information and translation review.
