"Managers should approve this before it goes out" is one of the most frequent customization requests in any Odoo rollout. It sounds simple: add a button, add a status, done. In practice the button is the easy part. The hard part is the rule behind it: which documents, above what amount, approved by whom, and what happens when that person is on leave. Teams that settle those questions first get a small, reliable change. Teams that skip them get a workflow that either blocks everything or protects nothing.
Start with what Odoo already does
Before asking for anything custom, check the approval steps that ship with the apps you use. Several are a setting away:
- Purchase. The purchase order approval setting asks a manager to approve orders above a minimum amount you choose.
- Expenses. Expense reports are submitted to a manager, who approves or refuses them before they are posted.
- Time Off. Each time off type can require no validation, approval by a time off officer, approval by the employee's approver, or both.
- Approvals app. In Odoo Enterprise, the Approvals app lets you define request types, such as a purchase request or a business trip, with named approvers.
If one of these covers the need, configure it and train people on it. A standard approval step is maintained by Odoo across version upgrades. A custom one is maintained by you.
When a custom workflow is justified
Custom approvals earn their place when the standard options stop matching how your business actually decides. Typical signals:
- You need more than one level, for example a department head up to one amount and a finance director above it.
- The approver depends on data on the record: the cost center, the branch, the product category, or the project.
- The document you want to control has no approval step in your setup today, such as a sales quotation with an unusually large discount, or a vendor bill that does not match its purchase order.
- Your auditors or your own policy require a clear record of who approved what, and when.
Write the rule before you request the workflow
A good approval request reads like a policy, not a feature. It should answer:
- Which document, at which step. "Purchase orders, before confirmation" is precise. "Purchasing" is not.
- The trigger. An amount, a percentage, a field value, or every record. State whether amounts include tax, and which currency applies when the document is in another currency.
- Who approves. A role or a group, not a named person, so the rule survives staff changes.
- Absence and delegation. Who approves when the approver is away? If the answer is "nobody", documents will queue up the first week someone travels.
- Rejection. Does a refused document go back to draft, get canceled, or stay open for edits? Is a reason mandatory?
- Edits after approval. If someone changes the amount after approval, does it need approving again? Usually it should, and this is the case most often forgotten.
- Visibility. How approvers find what is waiting for them, whether through activities, a filtered list, or email.
A notification is not a gate
Some needs can be met without code. Automation rules can assign a review activity to a manager when a field changes, which is often enough when the goal is awareness. But an activity does not stop anything: the document can still be confirmed while the review sits unread. If the requirement is that a document cannot move forward without approval, say so explicitly. That is a gate, and it needs to be built and tested as one.
How this works on Plemo
On Plemo, an approval request starts as a chat. The AI asks clarifying questions, which is where the checklist above gets answered, and it narrows requests that are too broad to build well in one pass. "Add approvals across purchasing and sales" becomes one document and one rule you can check first. You then approve a written spec before development starts, so the policy is on paper, including the rejection and re-approval behavior.
The change is delivered to a sandbox before anything reaches production. Test it with real roles, not just an administrator account, because an administrator usually belongs to every approver group and will not see what a regular user sees. Walk through every path: below the threshold, just above it, a rejection, an edit after approval, and a document in a second currency. AI usage is credit based, so a tightly scoped rule is also cheaper to build, and cheaper to adjust once people start using it.
Common mistakes
- Approving everything. If every document needs sign-off, approvers start clicking without reading, and the control becomes a formality.
- Naming a person instead of a role. The workflow breaks the day that person leaves or changes position.
- No path for urgent cases. Decide in advance who can approve when the usual approver cannot be reached.
- Testing only as an administrator. The workflow looks fine until the first real user meets it.
Approval rules sit where process design and development meet, and the right answer is sometimes a policy change rather than code. Our custom development team can help decide which controls belong in Odoo and which belong in your procedures.