Approval Workflow Plus
Visual approval engine for any Odoo model — Sales, Purchase, Invoices or your custom models. Multi-level, conditional, parallel. No code required.
See Approval Workflow Plus in action — full product walkthrough.
https://www.youtube.com/watch?v=S5J1-QjFLgo
Design Visually
Drag-and-drop flow designer with start, approval and end nodes, conditional branches and parallel paths. See the whole approval chain at a glance.
Test Before You Publish
Built-in flow simulator: pick a real record and a submitter, preview the exact approval path and approvers — before the flow ever goes live. Read-only, zero side effects.
Works on Any Model
Attach approval flows to Sales Orders, Purchases, Invoices, Partners or custom models. Hide buttons and lock records until approval passes.
How It Works
Create a Flow
Pick the target model, set the match domain, priority and company scope.
Design the Path
Drag nodes, connect them, set approvers, conditions, SLAs and automations.
Simulate
Verify the path and resolved approvers against real records — safely.
Publish
Documents now route through approval automatically. Iterate with new versions.
Features in Depth
Everything an approval engine needs for real-world processes — and the audit trail to prove it afterwards.
Visual Flow Designer
Build multi-level, conditional and parallel approval paths on a drag-and-drop canvas. Resolve approvers dynamically at runtime:
- Specific users or roles / groups
- A user or employee field on the document itself
- Department manager or direct manager
- Approval level chain (walk up the reporting line)
- Approval-rate thresholds, e.g. "60% of approvers must approve"
Flow Versions & Safe Publishing
Every change is a version. Publish and unpublish with confirmation guards, copy a version to iterate — and never break in-flight approvals: running requests always finish on the version they started with. Versions that have been used become immutable, keeping your audit history trustworthy.
Flow Simulator
Select a real record and simulate any submitter. The simulator computes the full path: which branches are reached, which are skipped by conditions, and who the approvers would be at each node — including manager-chain resolution based on the simulated submitter. Completely read-only: no requests, no logs, no notifications. Works on published, unpublished and locked versions alike.
Approval Panel on the Document
A live stepper right on the record's form view: completed, active and upcoming nodes, current approvers, and the full timeline with comments. Approve, reject, recall, transfer, add-sign or ask for an opinion — without ever leaving the document.
The panel can be expanded when users need the full approval context, and collapsed when they want a clean document form with the approval status still close at hand.
Smart Auto-Approval, Fully Audited
Skip if submitter and once-per-flow deduplication don't make people silently vanish from the flow. They generate real approval log entries flagged as automatic, count toward approval-rate thresholds, and stay visible in the timeline — so auditors always see exactly what happened and why.
Notifications that Reach People
Approvers are notified the moment their turn comes: a chatter notification, a direct Discuss message from OdooBot with a clickable link to the document, and email when the user's Odoo notification preferences and outgoing mail configuration allow it. Rejections notify the submitter, recalls notify pending approvers, add-signs and consultations notify the invited person, and consultation replies go back to whoever asked — comments included.
Button Control & Record Locking
Hide action buttons like Confirm until the approval passes (or permanently), and lock the record read-only while approval is running. Enforced in the view layer for every record state — including brand-new unsaved records — so there is no way around the flow.
Dashboard, Delegation & SLA
A personal approval dashboard shows what needs you: direct pending approvals, items delegated to you, overdue approvals and your history. Set up vacation delegation with date ranges. Give every node an SLA with early-warning hours, optionally computed on the company working calendar.
Core Concepts
How the pieces fit together — understand this and you can configure anything.
Design time
Runtime (per submitted document)
The rules the engine lives by
Business Configuration Guide
Configure approval from the business question first: which document needs control, when approval is required, who may submit, who must approve, and what the system should do after the decision.
Flexible Policy Design for Real Companies
Approval Workflow Plus is designed for organizations where one document type may need different approval policies by company, amount, department, customer, vendor or business unit.
Configure one approval flow for each company when local rules are different, while keeping a global flow as the default fallback.
Instead of forcing every exception into one huge diagram, split complex rules into several focused flows with clear match domains and priorities.
Business administrators can update one policy without touching unrelated approval flows, reducing risk when rules change.
Proxy Approval and Delegation
Use proxy approval when the original approver is temporarily unavailable, such as during vacation, travel or a short-term absence. The delegate acts on behalf of the original approver, but the audit trail still records both people.
This is different from transfer, where ownership of the approval is moved to another approver, and different from add-sign, where an extra approver is added to the node. Proxy approval is best for temporary coverage without changing the approval policy itself.
Recommended Setup Sequence
- Choose the business document model, such as Sales Order or Purchase Order.
- Write the match condition that decides when approval is required.
- Set the company scope and priority for multi-company routing.
- Define who may submit the document for approval.
- Design approval nodes, branches, approvers, rates and SLA rules.
- Configure automation actions, hidden buttons and record locking.
- Simulate with real records and submitters, then publish the version.
Multi-Company Matching Rule
Leave Company empty when the flow should be global and available to all companies. Configure Company only when the flow is a company-specific policy.
When a document has a company, the engine first looks for matching flows for that exact company. If no company-specific flow matches, it falls back to a global flow where Company is empty. Priority is then used to choose between multiple matching flows inside the same scope.
Business Recipes
Sales Order Approval
Model: Sales Order.
Condition: approve only high-value orders, discount exceptions or selected customers.
Approvers: sales manager, department manager, finance group or approval level chain.
Automation: hide Confirm before approval, then call action_confirm on approval completion.
Purchase Order Approval
Model: Purchase Order.
Condition: approve by amount, vendor category, department or project.
Approvers: buyer's manager, department manager, procurement group or multi-level chain.
Control: lock the PO during approval and use SLA warnings for urgent procurement.
Invoice or Payment Approval
Model: Invoice, bill or payment model.
Condition: approve before posting, validating or paying.
Approvers: accountant, finance manager, CFO group or document owner manager.
Control: hide Post / Validate / Pay buttons until the approval passes.
Master Data Approval
Model: Contact, product, vendor, price list or custom master data.
Condition: approve new records, sensitive changes or selected categories.
Approvers: data owner, compliance group or responsible department.
Automation: write status fields, archive rejected records or call a publish method.
Custom Model Approval
Model: any model from your own modules.
Condition: use fields already present on the custom record.
Approvers: fixed users, groups, record fields or manager chain from an anchor person.
Control: hide custom workflow buttons and call your existing model methods after approval.
Delegation and Absence Cover
Use when: approvers travel, take leave or temporarily transfer duties.
Configuration: create date-ranged delegation from the delegator to the delegate.
Audit: the delegate can act, and the log records both the delegate and the original approver.
Flow Configuration Fields
These fields define where the approval flow applies and how the business document is controlled before, during and after approval.
| Flow field | Business meaning | How to use it |
|---|---|---|
| Name | Readable policy name. | Use names business users recognize, such as SO Approval Above 10,000. |
| Model | The document type controlled by this approval flow. | Select Sales Order, Purchase Order, Invoice, Contact, Product or any custom model. |
| Domain | The condition that decides whether a record needs this approval. | Leave empty to match every record of the model. Use a domain such as [('amount_total','>',10000)] for conditional approvals. |
| Company | The company scope of the approval policy. | Leave empty for a global flow that applies to all companies. If a document has a company and a company-specific flow matches it, that company flow is preferred before global flows are considered. |
| Priority | Tie-breaker when multiple flows match in the same scope. | Use higher priority for more specific policies. Priority does not override the company-specific-before-global rule. |
| Submitter Fields | Who is allowed to submit this document for approval. | Leave empty to allow the record creator. Configure user or employee fields to allow document owners, salespeople, buyers or responsible employees. |
| Anchor Person Field | The person whose manager, department manager or reporting chain should be used. | Use salesperson, buyer, employee, owner or requester fields. If empty, the submitter is used. A node-level anchor can override this. |
| Working Calendar | Calendar used when SLA is calculated in working time. | Leave empty to use the company calendar. Configure it when different approval flows need different working-hour rules. |
| Recall Policy | Whether the submitter can pull back a submitted request. | Choose no recall, recall anytime, or recall before any human approval action. |
| Deduplication Rule | How repeated approvers are handled across the same flow. | Use once-per-flow when the same person may appear in multiple nodes and should not approve the same request repeatedly. |
| Dashboard Icon / Label | How the flow appears on the approval dashboard. | Use a short business label such as Sales Approval or PO Approval. |
| Hidden Buttons | Business action buttons users should not click before approval. | Hide buttons such as Confirm, Post, Validate, Approve or custom workflow buttons. |
| Lock Record During Approval | Whether the business document becomes read-only while approval is running. | Enable it for financial, purchasing and controlled master-data processes where changes during approval would invalidate the decision. |
Node and Approver Fields
Nodes describe each approval step. Each approval node resolves a set of approvers at runtime from the submitted document.
| Node field | Business meaning | How to use it |
|---|---|---|
| Node Type | Start, approval step or end of the process. | Use one Start node, one or more Approval nodes, and one or more End nodes for approved or rejected outcomes. |
| Approver Source | Where the approvers come from. | Choose users, groups, a document field, department manager, direct manager or approval level chain. |
| Specific Users | Fixed named approvers. | Use for small processes owned by known people. |
| Roles / Groups | Every user in selected Odoo groups can approve. | Use for teams such as Finance Manager, Procurement Approver or Compliance. |
| Record Field | Approver is taken from a field on the document. | Use owner, salesperson, buyer, requester, responsible user or employee fields. |
| Department Manager | Approver is the manager of the anchor person's department. | Requires employee and department manager data to be maintained. |
| Direct Manager | Approver is the anchor person's direct manager. | Use for line-manager approval based on employee hierarchy. |
| Approval Level Chain | Approvers are resolved by walking upward through managers. | Use for multi-level approvals where each management level must be included. |
| Approval Rate | The portion of approvers required for the node to pass. | 1.0 means everyone. 0.5 means half. Automatic approvals count toward the rate. |
| Skip If Submitter | Automatically approves when the submitter is also an approver. | Use it to avoid asking people to approve their own submission while keeping a visible automatic log entry. |
| Anchor Person Field | Node-level override for manager or level-chain resolution. | Use it when one node should follow a different person than the flow-level anchor. |
| SLA Duration | How long this node is expected to wait for approval. | Set hours for time-sensitive approvals and dashboard overdue tracking. |
| Use Working Calendar | Whether SLA ignores non-working time. | Enable it when weekends, holidays and working hours should affect due dates. |
| Early Warning | How long before the deadline the node becomes a warning item. | Use it to alert approvers before the SLA is actually overdue. |
Branch, Automation and Button Control
Branches decide where the request goes next. Automation and button control decide how the original document is changed or protected while approval is running.
| Configuration | Business meaning | How to use it |
|---|---|---|
| Transition Condition | Condition for taking a path from one node to the next. | Leave empty for an unconditional path. Use domains for amount, category, company, department or state-based branches. |
| Parallel Branches | Several next steps run at the same time. | Create multiple outgoing transitions from one node. A downstream join waits for every reachable branch. |
| Automation Trigger | When an action runs. | Use on enter, on approve, on complete, on reject or on timeout based on the business moment. |
| Call Method | Runs an existing method on the business document. | Use for standard actions such as confirm, post, validate or custom workflow methods. |
| Server Action | Runs an Odoo server action with the document in context. | Use when business logic already exists as a server action or needs admin-configurable logic. |
| Write Field Values | Writes values directly to the business document. | Use a Python dictionary such as {'state': 'draft'} for simple status or flag updates. |
| On Error: Stop | Blocks the approval if automation fails. | Use for critical actions where a failed update must not be ignored. |
| On Error: Continue | Logs the error and lets approval continue. | Use only for non-critical actions such as optional notes or reminders. |
| Show After Approved | Hides a button until approval passes. | Use when users may still click the button manually after approval. |
| Always Hidden | Prevents users from clicking a button manually at any time. | Use when the action must only be executed by approval automation. |
| Lock Record During Approval | Prevents edits while the request is running. | Use when approval should be based on a stable document snapshot. |
Common Use Cases
By amount, customer, salesperson or company — confirm automatically once approved.
By department, manager chain or approval level with SLA tracking.
Approve before validation or posting; lock the record while pending.
Partners, products, price changes — reviewed before they go live.
Any model from your own modules — no approval code to write.
Company-scoped flows with a global fallback and per-flow priorities.
FAQ
Yes. Any model can be an approval target — pick it on the flow, design the path, publish. The approval panel, button control and record locking attach to its form view automatically.
Both. The module depends only on base, mail,
web and resource. The Employees (hr) app is
required only if you use the manager, department-manager or
level-chain approver sources.
No. Every request is pinned to the version it started on and finishes there. New submissions use the newly published version.
No. Configured buttons are hidden by the engine for every record state — including brand-new unsaved records — and record locking keeps the document read-only while approval is running.
Every action is logged with user, timestamp and comment — including automatic approvals (flagged as such), delegate actions (both persons recorded), transfers, add-signs and consultations.
Need Help?
Questions before buying, help with configuration, or a feature request — we usually reply within 24 hours on business days.
Contact Support — yuze@x2soft.cnApproval Workflow Plus · Odoo 19 · License OPL-1 · by X2soft
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module