- Home
- Apps
- SaaS Tools
- Tier-Based Approval Validation
Illustrative previewA build-to-order Odoo module that enforces multi-tier approval sign-off on any record type before it can advance or be validated.
ECOSIRE scopes, builds, installs, and supports it for your Odoo 17, 18, or 19 instance.
What is Tier-Based Approval Validation?
A build-to-order Odoo module that enforces multi-tier approval sign-off on any record type before it can advance or be validated. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17, 18, or 19 instance. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $999.00 USD; request a quote for a scoped proposal.
Key Features
Built to order, done for you
No DIY setup — a working app, built, installed and supported by ECOSIRE.
- 1
You order
Start with a one-time build price. We scope it with you at kickoff.
- 2
We build & install
ECOSIRE builds, configures and installs it on your Odoo.
- 3
Go live + support
You go live in about one working week, with two weeks of go-live support. Defects in the code we deliver are fixed free of charge.
Technical Specifications
- Odoo Compatibility
- Odoo 17, Odoo 18, Odoo 19
- Editions
- Enterprise & Community
- License
- Licence confirmation required
- Python Requirement
- Python 3.10+
- Database
- PostgreSQL 12+
About this Product
Most teams hit the same wall as they grow: a purchase order, expense, journal entry, or custom record needs more than one person's blessing before it becomes official, but Odoo's out-of-the-box states only know "draft" and "confirmed." The native activity and approval features cover a few standard documents, and Odoo Studio can bolt on a single approver flag, but neither gives you a configurable ladder of approval tiers with escalation, delegation, amount thresholds, and an auditable trail across arbitrary models. So the rules end up living in email threads and spreadsheets, and "who approved this and when" becomes a monthly reconciliation headache. That is exactly where a typical off-the-shelf apps.odoo.com module also runs out of road: it assumes one document type, one hierarchy, and one company.
Tier-Based Approval Validation is a productized module ECOSIRE builds to your specification. Technically, it introduces an abstract tier.validation mixin that you inherit into any target model — purchase.order, account.move, sale.order, hr.expense, or your own custom models.Model — so that a record cannot leave its pre-approval state until every configured tier has signed off. Tier definitions are stored records that carry a Python or domain-based condition (for example amount_total > 5000), an approver group resolved via res.groups or a computed @api.depends field, a sequence for ordering, and flags for whether approval is required, whether the requester may self-approve, and whether the tier can be delegated. Reviewer assignment, review state, and the full decision history (who, which tier, timestamp, and comment) are persisted in dedicated models so nothing is inferred after the fact. Enforcement is layered: server-side @api.constrains and overridden write/action methods block state transitions in the ORM (so the rule holds over the XML-RPC/JSON-RPC API and scheduled actions too, not just in the UI), while OWL/XML view extensions add validate and reject buttons, a status widget, and a chatter-logged audit note. Optional automated actions and ir.cron jobs handle reminders and time-based escalation to the next tier, and every gate is enforced with ir.model.access.csv plus record rules so approvers only see what they are entitled to.
Because this is build-to-order, we start from your real approval matrix rather than a generic template. After a short scoping call we confirm the target models, the tier ladder and thresholds, the group/hierarchy resolution logic, multi-company boundaries, and any QWeb approval-report or notification requirements, then hand you a fixed quote. We build against your Odoo edition and version (17.0, 18.0, or 19.0; Community and Enterprise differences such as the Enterprise Approvals app are handled explicitly), deliver the packaged module with its __manifest__.py, migrate any existing in-flight records, and validate everything on a staging database before go-live. Typical delivery is one working week from confirmed scope.
Pricing starts from $999 (indicative, single-company base scope); the number of target models, multi-company or multi-hierarchy tier logic, delegation/escalation depth, and localization or data-migration volume increase the quoted scope. You receive a firm fixed quote after the scoping call — never a surprise invoice.
What you get
- Installable, version-pinned module source for your Odoo edition (17.0, 18.0, or 19.0) with a complete `__manifest__.py` and dependency declarations
- Installation and configuration on your instance, including tier definitions, approver groups, thresholds, and target-model wiring
- Technical documentation covering the models, `tier.validation` mixin, security rules, and extension points for your developers
- End-user guide plus a live training session for approvers and requesters on the validate/reject/delegation flows
- UAT on a staging database with your real approval scenarios, plus a documented rollback plan before production cutover
- Data migration of any in-flight records into the new tier states so existing documents are not stranded
- Post-go-live support window for defect fixes and configuration adjustments after launch
- Git repository handover with full commit history and tagged release for your version
Who this is for
Finance & Controlling Lead
Needs enforced multi-level sign-off on journal entries, vendor bills, and payments with amount thresholds and a defensible audit trail for internal control and external audit, beyond what native Odoo states provide.
Procurement / Operations Manager
Wants purchase orders and requisitions routed through department-head and budget-owner tiers automatically, with escalation when approvers stall, so nothing gets confirmed without the right authority.
Odoo Admin / IT Manager
Runs the company's Odoo and needs a maintainable, security-scoped approval layer that applies across several models and survives upgrades, rather than brittle Studio flags or scattered automated actions.
Compliance / Internal Audit Officer
Requires a persisted, timestamped record of who approved what and when across document types, enforced at the ORM level so API and background writes cannot bypass the controls.
How Tier-Based Approval Validation Compares
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Scope across models | Any model you specify via a reusable mixin | Whatever you build, from scratch each time | Usually one or a few fixed document types | Limited to a handful of standard documents |
| Tier logic & thresholds | Configurable ladders with amount/domain conditions and escalation | Possible but you design and maintain it all | Basic multi-step, limited conditional routing | Single-step or none on most records |
| API/import enforcement | ORM-level gate holds over XML-RPC, imports, cron | Only if you remember to override every path | Often UI-only, bypassable via API | State changes not centrally gated |
| Audit trail | Persisted approver/tier/time/comment plus chatter | Depends on your implementation effort | Partial, varies by product | Chatter notes only, no structured tier record |
| Fit to your process | Built from your real approval matrix after scoping | Fully bespoke but higher cost and risk | Generic; you adapt process to the module | You adapt to Odoo's fixed behavior |
| Delivery & cost | Fixed quote from ~$999, one working week | High effort, open-ended time and budget | Low upfront license, self-implemented | Included but insufficient for tiered sign-off |
| Support & handover | Training, support window, git repo handover | Your team owns it entirely | Vendor support varies, no source guarantee | Standard Odoo support only |
| Version coverage | Built for your 17.0/18.0/19.0, Community or Enterprise | You port it each upgrade | May lag on newer versions | Tied to your current Odoo release |
Frequently Asked Questions about Tier-Based Approval Validation
How long does delivery take?
This is a build-to-order module, not an instant download. Typical delivery is one working week from confirmed scope, depending on how many target models, tiers, and integrations are involved. The scoping call establishes the exact timeline in your fixed quote.
How does pricing and scoping work?
Pricing starts from $999 as an indicative from-price for a single-company base scope. After a short scoping call we confirm your target models, tier ladder, thresholds, and any migration or reporting needs, then issue a firm fixed quote. You approve the quote before we build — no open-ended billing.
What about support and updates after go-live?
Every build includes a post-go-live support window for defect fixes and configuration tweaks. Because you receive the full source and git repository, your team can maintain it independently, and we offer ongoing support or version-upgrade engagements (for example moving from 18.0 to 19.0) as a separate scoped item.
Which Odoo versions and editions do you support?
We build for Odoo 17.0, 18.0, and 19.0, on both Community and Enterprise. Enterprise-specific differences (such as the built-in Approvals app) are handled explicitly during scoping so the tier logic complements rather than conflicts with native features.
Can it apply to our own custom models, not just standard documents?
Yes. The core is an abstract `tier.validation` mixin that we inherit into whatever models you specify — standard ones like `purchase.order` or `account.move`, or your own custom `models.Model`. Any record type that needs multi-tier sign-off can be gated.
Can approvers bypass the rules through the API or imports?
No. Enforcement lives in overridden ORM write/action methods and `@api.constrains`, so the gate applies to XML-RPC/JSON-RPC calls, data imports, and scheduled jobs — not just button clicks in the web client. Access is further constrained by `ir.model.access.csv` and record rules.
What happens to records already in progress when we go live?
We migrate in-flight records into the appropriate tier states as part of delivery, and validate the outcome on staging during UAT. A documented rollback plan is in place before the production cutover, so existing documents are never stranded.
Related Modules

Telr Payment Gateway for Odoo
A build-to-order Telr payment provider for Odoo 17/18/19 — accept cards, mada & Apple Pay with 3DS and webhook reconciliation.

Thailand e-Tax Invoice & Receipt
A build-to-order Odoo module that turns a posted customer invoice or receipt into a digitally signed, ETDA-conformant Thai e-Tax document, delivers it to the buyer, and keeps a compliant archive. ECOSIRE scopes, builds, installs and supports it on your Odoo 17.0, 18.0 or 19.0.

Total Items and Total Quantity in POS
A build-to-order Odoo Point of Sale extension that surfaces the total distinct line items and the total ordered quantity live on the POS order screen, receipt, and reporting. ECOSIRE builds, installs, and supports it for your Odoo 17/18/19 estate after a short scoping call.

Trust Payments (3DS) Gateway for Odoo
A build-to-order Odoo payment provider that connects Sales, eCommerce, and Invoicing to Trust Payments with full 3DS2/SCA card acceptance, a hosted payment page via JWT, and webhook-driven reconciliation. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17/18/19.
Tier-Based Approval Validation
A build-to-order Odoo module that enforces multi-tier approval sign-off on any record type before it can advance or be validated. ECOSIRE scopes, builds, installs, and supports it for your Odoo 17, 18, or 19 instance.
- Abstract `tier.validation` mixin inheritable into any model (`purchase.order`, `account.move`, `sale.order`, `hr.expense`, or custom `models.Model`) so records cannot advance until every required tier approves
- Configurable tier definition records with sequence-ordered ladders, per-tier approver `res.groups`, and Python/domain conditions such as `amount_total > 5000` evaluated per record
- Server-side enforcement via overridden write/action methods and `@api.constrains` so the gate holds over the XML-RPC/JSON-RPC API and scheduled jobs, not only in the web client
- Amount- and field-threshold routing that activates or skips tiers dynamically based on `@api.depends` computed values on the target record