Short answer: Improve Odoo approvals after go-live by separating creation, review, approval, and execution; keeping the standard path short; and assigning every recurring exception an owner, delegate, response window, and return path. Start with real stalled transactions and workarounds rather than adding another approval layer.
Go-live reveals conditions that workshops rarely capture in full. An approver is away. A request reaches Finance without a cost centre. A small routine purchase waits for an executive. A decision happens in a chat and is entered into Odoo later. The software is available, yet the operating experience remains cumbersome.
That is a post-go-live usability problem to diagnose, not automatic proof that the implementation failed. The useful questions are where requests wait, why users bypass the system, and which decisions should be simplified, delegated, or treated as explicit exceptions.
Separate Access, Review, Approval, and Execution
| Control | Core question | Example | Common design mistake |
|---|---|---|---|
| Access | What may this user see, create, or change? | A buyer creates requests for their company | Granting broad rights to solve one edge case |
| Review | Who confirms that the request is complete and operationally valid? | A department lead checks quantity and cost centre | Making every reviewer a final approver |
| Approval | Who owns the commitment or exception decision? | An authorised manager approves above an internal threshold | Routing every value to the same executive |
| Execution | Who acts after approval? | Procurement converts the approved request into an order | Treating approval as a substitute for execution checks |
Exact capabilities vary by Odoo version, installed applications, configuration, and custom modules. Validate the design in the company’s actual environment.
Friction Signals Worth Investigating
- Correct requests stop because an approver is unavailable and no delegate exists.
- Decisions happen in email or messaging apps and are recorded later.
- Requests return repeatedly for information that could have been validated earlier.
- The same exception is solved through a different conversation each time.
- Users ask for manager-level access to complete one routine task.
- Nobody can identify whether a delay sits with the requester, reviewer, or approver.
- Notification volume makes urgent items harder to identify.
These signals justify a workflow review. They do not, by themselves, justify opening access or adding controls.
Design the Standard Path First
Define readiness and completion
Specify the data required before review, the point at which a decision is final, and what becomes executable afterward. “Manager reviews” is too vague; name the role, decision scope, and next action.
Assign responsibility to roles
Build ownership around roles such as Branch Manager or Procurement Manager. Then define who may activate a delegation, its duration, and what happens to already-pending items.
Match control to risk
Different values, expense types, projects, branches, or exceptions may warrant different controls. The rule must be understandable and testable. The aim is to protect material decisions without placing routine work in one queue.
Keep data correction separate from approval
An incomplete request should return with a clear reason before it consumes approval time. Review establishes readiness; approval makes the decision.
Make Exceptions a Designed Process
| Exception | Owner | Required decision | Absence cover | System evidence |
|---|---|---|---|---|
| Urgent out-of-cycle request | Process owner | Accept or reject priority | Named delegate | Reason and decision date |
| Internal threshold exceeded | Higher authority | Approve the exception | Predefined substitute | Amount and justification |
| Change after approval | Process owner and Finance where relevant | Reopen or reject change | Depends on transaction | Change history and renewed review |
| Access conflict | System administrator and process owner | Remove conflict or narrow the task | Governance owner | Documented and tested change |
For every recurring exception, define ownership, acceptance criteria, required information, response window, and the condition that returns it to the standard path. Otherwise it remains a private conversation with weak traceability.
Delegation and Escalation Need Boundaries
A delegation should be limited by process, date, authority, and review responsibility. It should not mean account sharing or permanent elevated access. Escalation should expose an overdue decision and its current owner, not copy leadership into every transaction.
Two-Week Review Checklist
- Select one high-friction process.
- Sample completed, delayed, returned, and cancelled transactions.
- Classify delays as data, access, absence, exception, or configuration issues.
- Map requester, reviewer, approver, executor, and delegate.
- Remove approvals that do not change a decision or mitigate a defined risk.
- Define the three most frequent exceptions and their owners.
- Test realistic cases with actual user roles in an appropriate environment.
- Observe a complete business cycle before expanding the change.
Measure the Operating Result
Track approval lead time, returns for missing data, decisions made outside Odoo, items stranded with unavailable users, recurring exception reasons, and the proportion of items with a visible current owner. Compare like-for-like periods where possible. These indicators guide improvement but may also reflect seasonality, staffing, or transaction volume.
When Customisation Deserves Consideration
Start with available Odoo configuration. Consider customisation when a decision rule is stable, important, and cannot be represented clearly with the current setup, and when maintenance and upgrade implications are understood. Avoid encoding a temporary policy or compensating for missing process ownership.
See the official Odoo access-rights documentation for standard concepts, and verify that the documentation matches your deployed version.
Frequently Asked Questions
How are permissions different from approvals?
Permissions govern what a user can access or perform. An approval path assigns review and decision responsibility under defined conditions. A user may create a request without authority to approve it.
Are more restrictions always safer?
No. Excessive restrictions can delay work and encourage off-system workarounds. Controls should match risk and be tested with users.
How should approver absence be handled?
Use time-bound delegation with a defined scope, authority limit, and reviewer. Avoid shared accounts and indefinite elevated access.
Should an incomplete request be rejected?
Usually it should be returned for correction with a clear reason. Rejection should represent a decision not to proceed, not merely missing information.
Which workflow should be reviewed first?
Choose a frequent process with visible business impact and enough real cases to analyse. Rare edge cases are a poor starting point.
Next Step
If Odoo is live but requests still depend on calls and messages to move, ask Neyar Solutions to review one approval path with its users. We can map roles, delays, delegations, and exceptions, then help prioritise practical post-go-live improvements.
Suggested internal link: How to Govern Multi-Branch Reporting in Odoo
