Multi-Level Approvals & Workflow Engine

Name: Multi-Level Approvals & Workflow Engine
Brand: ECOSIRE
SKU: multi-level-approvals-workflow

Temel Özellikler

Define ordered approval stages per target model (sale.order, purchase.order, account.move, hr.expense, stock.picking, project.task, or any custom model) with no Python required

Role- and condition-based routing: assign each stage to a res.groups role, a related approver field (e.g. the record's department manager), or a domain condition evaluated against the document

Sequential AND parallel approval modes — chain tiers one after another, or require several approvers in the same stage to sign off simultaneously

Amount- and field-threshold rules using Odoo domains (e.g. amount_total > 50000 pulls in the CFO tier) recomputed via @api.depends whenever the source record changes

Time-based escalation: if an approver does not act within a configured SLA, an automated action reassigns or bumps the request to the next authority

Delegation rules so an approver on leave can hand their pending approvals to a backup, with the substitution recorded in the audit trail

Email approval requests plus in-app Discuss/activity notifications with one-click Approve, Reject, and Delegate actions

Reject-with-reason and send-back-for-revision flow that resets the document to draft and notifies the requester

Immutable, timestamped approval-history model logging who approved/rejected/delegated, when, from which stage, and any comment — a complete audit trail

Segregation-of-duties record rules that prevent a requester from approving their own document and hide approval buttons from unauthorized users

OWL approval-timeline widget on the document form showing current stage, pending approvers, and completed steps at a glance

QWeb approval-certificate report attachable to the record or emailed as PDF for compliance evidence

XML-RPC / JSON-RPC endpoints to submit, approve, and query approval requests from external systems

Configurable document locking so a record can't be edited or confirmed until its approval chain is fully cleared

Multi-company aware: approval definitions, roles, and record rules respect company_id boundaries

Kanban/list dashboard of pending approvals filtered per user, with My Approvals shortcut and overdue highlighting

Siparişe özel, sizin için baştan sona

Kendiniz kurmanıza gerek yok — ECOSIRE tarafından geliştirilen, kurulan ve desteklenen çalışır bir uygulama.

Sipariş verirsiniz

Tek seferlik geliştirme fiyatıyla başlayın. Kapsamı başlangıçta sizinle birlikte belirleriz.

Geliştirir ve kurarız

ECOSIRE, Odoo ortamınızda geliştirir, yapılandırır ve kurar.

Yayına alma + destek

Yaklaşık 2–4 haftada yayına alırsınız; lansman sonrası bir destek süresi de dahildir.

Bu Ürün Hakkında

Odoo's built-in approvals are narrow: the Approvals app covers a fixed set of request types, and beyond that you fall back to manual "state" fields, a lone approver group, or a hard-coded validation button. The moment Finance or Operations needs a real control matrix — "purchase orders over 50,000 need the department manager, then the CFO; anything above 250,000 also needs the CEO; if the manager is on leave it escalates after 48 hours" — native Odoo simply doesn't express it.

The Multi-Level Approvals & Workflow Engine is a build-to-order Odoo module that ECOSIRE designs, develops, installs, and supports for your specific control requirements. It layers a configurable approval and workflow layer on top of ANY Odoo model — sale.order, purchase.order, account.move, hr.expense, stock.picking, project.task, or a custom model you own — without you writing a single line of Python.

At the core is an approval-definition model (models.Model) that lets an administrator define, per target model, an ordered set of stages. Each stage carries an approver rule expressed as a role (an ir.model.access / res.groups mapping or a related field like the record's department manager), a condition domain evaluated against the record, and a mode (sequential or parallel). Computed fields with @api.depends recalculate the required approver set and the live approval status whenever the source document changes, so a purchase order that crosses a threshold automatically pulls in the next tier. Every approval, rejection, delegation, and escalation is written to an immutable approval-history model, giving you a complete, timestamped, per-user audit trail that satisfies internal-control and SOX-style review.

Because ECOSIRE builds this to your rules, the engine is not a black box. We ship the full addon — __manifest__.py, models, views (XML list/form + OWL widgets for the approval timeline), security via ir.model.access.csv and record rules that stop a requester from approving their own document, QWeb approval-certificate reports, and automated actions/server actions that fire the escalation and notification logic. Approval requests reach approvers by email and as in-app Discuss/activity notifications with one-click Approve / Reject / Delegate, and the whole engine is reachable over Odoo's XML-RPC and JSON-RPC API so external systems can submit and query approvals.

The module targets Odoo 17, 18 and 19 and works on both Community and Enterprise (we flag any stage feature that depends on an Enterprise-only app before we build). Typical delivery is 2–4 weeks depending on how many models and control tiers you need — you receive a working, tested, documented module deployed on your instance, not a template to finish yourself.

Ne elde edeceksin

The complete, installable Odoo addon (__manifest__.py, models, views, security, reports, data) versioned for your Odoo 17, 18 or 19 instance

Configured approval definitions and workflow rules for the specific models and control tiers agreed in your requirements

Security layer: ir.model.access.csv, record rules enforcing segregation of duties, and role/group mapping to your org structure

QWeb approval-certificate report template plus email templates for request, escalation, and rejection notifications

Deployment onto your environment (Odoo.sh, ECOSIRE-managed, or your own server) with a smoke test of each approval path

Administrator and end-user documentation covering how to add stages, edit rules, delegate, and read the audit trail

A live handover training session for your admins and approvers (recorded on request)

A post-delivery support window for bug fixes and adjustments, with an optional ongoing maintenance and version-upgrade plan

Bu kimin için

Finance controllers enforcing spend authority

CFOs and controllers who need documented, tiered sign-off on purchase orders, vendor bills, and expenses — with thresholds, an audit trail, and segregation of duties that stands up to internal or external review.

Operations and procurement managers

Ops leads routing quotations, purchase orders, and stock transfers through department managers and budget owners, who need escalation when approvers stall and delegation when someone is on leave.

Compliance, risk and internal-audit teams

Governance stakeholders who require an immutable, timestamped record of every approval decision, enforced control policies, and exportable evidence (QWeb certificates) for audits and regulatory checks.

Multi-Level Approvals & Workflow Engine Nasıl Karşılaştırılır

Kriter	ECOSIRE	Özel Yapı	Rakip
Multi-level, multi-tier chains (sequential + parallel)	Fully configurable per model, no code	Possible but must be hand-coded per case	Often single-tier or fixed request types
Condition/threshold-based routing (e.g. amount > X)	Domain-driven rules recomputed via @api.depends	Yes, if you write and maintain the logic	Sometimes, limited to preset fields
Escalation on SLA breach + delegation for absent approvers	Built via automated actions to your rules	Rarely built — extra effort each time	Uncommon in off-the-shelf apps
Immutable, timestamped audit trail	Dedicated approval-history model, per decision	Only if you design it in	Basic log if any
Segregation of duties (can't approve own doc)	Enforced with record rules + access controls	Depends on developer diligence	Varies, often not enforced
Works on any model incl. custom, on 17/18/19 Community & Enterprise	Yes — scoped and tested to your models	Yes, but per-model rework	Usually fixed models / version-locked
Ownership: who fixes it and upgrades versions	ECOSIRE builds, supports, and migrates	Your team / freelancer maintains it	Vendor SLA varies; may lag Odoo releases

Multi-Level Approvals & Workflow Engine hakkında Sıkça Sorulan Sorular

Is this an instant download from the Odoo App Store?

No. This is a build-to-order module. ECOSIRE designs, develops, installs, and supports it around your specific approval rules and target models. You are not buying a generic ZIP to finish yourself — you receive a working, tested module deployed on your instance.

How long does delivery take, and what's the lead time?

Typical delivery is 2–4 weeks from confirmed requirements. Simpler scopes (one or two models, a few tiers) land closer to two weeks; larger control matrices with escalation, delegation, and API integration take toward four. We agree the timeline and milestones before we start and keep you updated through build, test, and handover.

What about support and updates after delivery?

Every build includes a post-delivery support window for bug fixes and adjustments. Beyond that, we offer an optional ongoing maintenance plan that covers enhancements and keeps the module compatible when you upgrade across Odoo 17, 18, and 19. Odoo version migrations of the module are handled under that plan or as a scoped task.

Which Odoo versions and editions does it support?

We build for Odoo 17, 18, and 19, on both Community and Enterprise. Most of the engine relies on core framework features (models, record rules, automated actions, QWeb, activities), so it runs on Community. If a stage you want depends on an Enterprise-only app, we flag it during scoping.

Can it apply approvals to our custom models, not just standard Odoo documents?

Yes. The engine attaches to any model — standard (sale.order, purchase.order, account.move, hr.expense, stock.picking) or a custom model your team owns. During scoping we map each model to its stages, approver roles, and conditions.

How does it stop someone from approving their own request?

Segregation of duties is enforced with Odoo record rules and access controls. A requester never sees an approve button on their own document, and each approver only acts on the stages assigned to their role. Every decision — including delegations and escalations — is written to an immutable approval-history log for audit.

Can other systems submit or check approvals?

Yes. The module exposes its approval actions over Odoo's XML-RPC and JSON-RPC API, so an external portal, ERP, or automation can raise an approval request and query its status programmatically. We document the endpoints as part of handover.