Odoo Approvals: A Practical SME Guide to Centralized Sign-Offs

What Odoo Approvals Actually Does

Odoo Approvals is an Enterprise-only productivity application that centralizes internal approval requests — travel, procurement, expenses, payments, contracts, job referrals, and more — into a single hub with Kanban dashboards, replacing ad-hoc email and chat sign-offs. Each request carries a defined lifecycle, chatter history, attachments, and activities that notify the right approver.

The core building block is the Approval Type (also called a category, backed by the model approval.category), configured under Approvals → Configuration → Approval Types. Each type declares which form fields apply (amount, quantity, date, partner, product, reference, location, payment method) and whether each field is hidden, optional, or required. The same record defines the approver chain, the sequence logic, and the minimum number of approvals needed.

• →Centralizes requests for travel, procurement, expenses, payments, contracts, and referrals into one Kanban hub.
• →Built around Approval Types (approval.category) — each type defines fields plus the approver chain.
• →Lifecycle stages are color-coded: To Submit → Submitted → Approved / Refused / Cancelled.
• →Enterprise-only; there is no Community edition of the standalone Approvals app.

What Is Approval Routing? The Generic Model

Approval routing is the structured process of directing requests, transactions, or documents through predefined approval paths to the appropriate stakeholders, based on rules such as amount, category, department, or risk level. It ensures each approval happens in the correct sequence and by an authorized person before the action is executed — whether that is releasing a payment, confirming a purchase order, or publishing a contract.

Most SMEs first meet approval routing inside a single ERP module: a purchase order that needs a manager's signature above a spending limit, or an expense report that routes to a team approver. The same idea scales across the whole business. Routing rules evaluate criteria like transaction value or document type, the request is forwarded through a multi-level approval chain, and final approval triggers the downstream action — creating an RFQ, posting a journal, or releasing a payment.

Four routing patterns cover almost every real-world process. Sequential routing moves a request from one approver to the next in a fixed order (manager, then finance head, then CFO). Parallel routing sends the request to several approvers at once, useful when two independent budget holders must both sign off. Conditional routing changes the path based on data — the amount tier, the vendor category, or the department — so a $3,000 expense stops at the manager while a $30,000 one escalates to finance. Dynamic routing adapts further, using rules and increasingly AI-driven logic to choose the shortest compliant path.

• →Routing rules: logic based on value thresholds, departments, or risk levels.
• →Approval hierarchies: defined chains of authority (L1 manager → L2 director → L3 executive).
• →Approval matrices: a table mapping request type and amount tier to the required approver set.
• →Workflow triggers: events that initiate, escalate, or auto-delegate an approval.

Approval Types: The Builder You Configure by Filling a Form

Odoo Approvals has no visual drag-and-drop flowchart canvas. The Approval Type form IS the builder. You add approvers, mark each one Required (or optional), and toggle Approver Sequence on or off. When Approver Sequence is enabled, approvers must act in order — this is sequential, multi-level routing. When it is disabled, approvers act in parallel, and you can set a minimum-approvals threshold such as 1 of N or 2 of N.

Requesters can also add an approver directly on a specific request, which is useful for one-off exceptions without editing the type itself. This covers the vast majority of SME scenarios: a travel request that needs a line manager then finance, a procurement request that needs two of three budget holders, or a payment request that needs a single controller below a threshold.

Sequential vs Parallel, and Where Domain Routing Lives

The distinction that catches most SMEs: the standalone Approvals app does NOT do runtime, condition-based routing. You cannot say inside one type 'if amount > 25,000, automatically add the CFO.' Routing is static per type. For amount tiers, the standard pattern is to define separate Approval Types — a 'Small Expense' type and a 'Large Payment' type — each with its own approver list, rather than one type with branching logic.

True domain-based conditional routing is a separate feature: Odoo Studio Approval Rules. Per the official Studio documentation, an Approval Rule is used 'to define the criteria for when an approval is required before an action can be performed using a button.' It adds an approval step to any button action (Confirm, Validate, Post) using a filter such as [('amount_total', '>', 10000)], an Approval Order, and an Exclusive Approval option. Approval Rules live on the document button, not in the Approvals app — so for multi-step conditional document approvals inside Sales, Purchase, or Accounting, use Studio Approval Rules, not the Approvals app.

1. 01
   Create one Approval Type per business scenario

   Travel, procurement, payments, contracts — each gets its own type with explicit Required approvers, sequence, and minimum count.

2. 02
   Decide sequential vs parallel

   Enable Approver Sequence for ordered chains (manager then finance). Disable it for parallel sign-off with a minimum-approvals threshold.

3. 03
   Use Studio for conditional document approvals

   When a button like Validate needs a conditional sign-off based on amount or partner, add a Studio Approval Rule with a domain filter rather than trying to branch inside the Approvals app.

4. 04
   Keep audit in chatter

   Rely on chatter history and activities for the audit trail and nudges; do not build parallel tracking in spreadsheets.

Multi-Level Routing Patterns & Threshold Matrix

Amount-threshold routing is the pattern SMEs adopt first: the higher the value, the more levels of approval a request clears. A common structure routes invoices under $5,000 to a single manager, invoices from $5,000 to $20,000 to the manager and then the finance controller, and anything above $20,000 through a third executive level before payment is released. Each tier adds scrutiny exactly where the financial risk grows, without burdening low-value, routine requests with a multi-step chain.

Two safeguards keep multi-level chains from stalling. Delegation lets an approver who is out of office name a backup, or lets an administrator pre-assign one — so a vacation never freezes a payment run. Escalation timers go further: if an approver does not act within a set window (often 48 hours), the request is automatically re-routed to their manager or a designated backup. The rule 'if not reviewed within 48 hours, route to the backup approver' eliminates the single most common cause of approval delays: a request sitting untouched in one inbox.

Where Odoo fits this picture is the honest distinction. The standalone Approvals app handles sequential and parallel chains with a minimum-approvals threshold, but its routing is static per Approval Type — it does not branch at runtime on amount, and it has no built-in escalation timer. For true conditional, amount-threshold routing on a document button, Odoo Studio Approval Rules apply a domain filter. For native escalation timers and hierarchy-based delegation, Dynamics 365 Finance & Operations workflow and Business Central Approval User Setup are the more complete engines.

How Approvals Connects to Purchase, Expenses, and Time Off

The Approvals app is a hub, but the native Odoo apps already have their own approval paths — the Approvals app supplements rather than replaces them. The approvals_purchase companion Enterprise module adds a Purchase Request approval type; once a request is approved, a manual 'Create RFQs' button on the request generates a draft purchase.order (RFQ). It does not auto-create the RFQ — a user still clicks the button — and the native Purchase app's own order-approval threshold is an independent feature.

Expense reports are approved natively in the Expenses app (under Expenses to Process, requiring Team Approver rights), not through the central Approvals app. An optional hr_expense_approvals companion module can bridge high-value expense sheets through Approvals for centralized governance, but it is supplemental, not a replacement for the native path. Time Off (hr.leave) has its own native manager validation in the Time Off app, configurable per leave type for one or two approval levels, with the Approvals app acting as a supplemental layer. Manufacturing has no direct tie-in — work-order and MO confirmation is native, and PLM has a separate ECO-stage approval concept.

• →approvals_purchase adds a Purchase Request type and a manual 'Create RFQs' button — no auto-RFQ.
• →Day-to-day expenses are approved natively in Expenses; the hr_expense_approvals bridge only routes high-value sheets.
• →Time Off uses native 1–2 level manager validation; Approvals is supplemental, not a replacement.
• →Manufacturing MO confirmation is native; PLM ECO stage approvers are a separate feature.

Measuring Approval Routing: The Metrics That Matter

You cannot improve an approval process you do not measure. Four metrics tell you whether your routing is actually working, and each points to a specific fix when it drifts.

Approval cycle time is the total elapsed time from submission to final sign-off — the headline number for how fast work moves, with a healthy benchmark under 48 hours for standard requests. When cycle time creeps past that, the cause is almost always a missing escalation path or a single approver with no backup. First-time approval rate is the share of requests approved without being sent back for changes; above 70% signals that your submission forms and approval criteria are clear, while a lower rate means requesters are missing required context up front. SLA compliance rate measures how often approvals finish within their defined window — above 85% indicates a workflow that respects its own rules. Bottleneck frequency flags the specific stage or person that stalls more than roughly 20% of requests, telling you exactly where to add a delegate, split the load, or simplify the form.

None of these require a separate analytics tool when approvals live inside your ERP or approval hub — the events accumulate as part of the normal workflow. The same chatter history and activity log that Odoo uses for its audit trail also exposes who approved what, and how long each step took, so cycle time and bottleneck data are available without a second system.

The Dynamics 365 Equivalent: Power Automate Approvals + F&O Workflow

Microsoft has no single direct equivalent to Odoo Approvals — the closest match is a layered stack. Power Automate Approvals, plus the Microsoft Teams Approvals app, are the closest functional match to Odoo's centralized, model-agnostic hub. The 'Start and wait for an approval' action supports five modes: Approve/Reject – Everyone must approve; Approve/Reject – First to respond; Custom Responses – Wait for all responses; Custom Responses – Wait for one response; and Sequential. Approvers can be assigned by email, Microsoft 365 group, or dynamically, and responses are delivered through Outlook, Teams, or the Power Automate portal. Approvals are stored in Dataverse.

This maps cleanly to Odoo's Approval Types plus sequential/parallel plus minimum-approvals logic. The Microsoft Teams Approvals app sits on top of Power Automate and lets users create and act on approvals directly in Teams without building a full flow — handy for ad-hoc and custom requests, with responses also actionable from Outlook.

For structured ERP document approvals — purchase requisitions, expense reports, journals, vendor changes — Dynamics 365 Finance & Operations ships a mature native workflow system with a graphical workflow editor, Approval elements, per-step conditions, hierarchy-based assignment (Participant, Hierarchy, Workflow user, User), completion policies (single, majority, percentage, all), escalation, and Approve / Reject / Delegate / Request change actions. Business Central has its own Approval User Setup with sequence numbers controlling order and groups enabling parallel steps, plus Microsoft-provided workflow templates (MS- prefix) and Power Automate connectors that extend BC approvals into low-code flows.

• →Power Automate Approvals + Teams Approvals app = closest match to Odoo Approvals' centralized hub.
• →Five approval modes in Power Automate, including Sequential and 'First to respond' — maps to Odoo's sequence and minimum-approvals logic.
• →D365 Finance & Operations native workflow is the parallel to Odoo's per-app approvals (Purchase threshold, Expenses Team Approver, Time Off manager validation).
• →Business Central Approval User Setup + MS- workflow templates cover sales and purchase documents for SMEs.

Choosing the Right Approval Stack for Your SME

For an SME already standardized on Microsoft 365 and Dynamics 365, Power Automate Approvals plus the Teams Approvals app is usually the pragmatic default: it is license-bundled, surfaces sign-offs where staff already work (Outlook and Teams), and the 'First to respond' and Sequential modes cover the same ground as Odoo's Approval Types. Choose the F&O or Business Central native workflow when you need hierarchy-based routing, escalation, and completion policies tied to specific ERP documents.

For an SME running Odoo as its ERP, the Approvals app is the right hub for cross-cutting custom requests that do not belong to a single document — travel, contract review, job referrals — while Studio Approval Rules handle conditional sign-offs on the document buttons themselves. If you run both platforms (as many dual-stack SMEs do), keep the principle consistent: model-agnostic custom requests belong in the central hub (Approvals app or Power Automate), and document-embedded conditional approvals belong on the button (Studio Approval Rules or F&O/BC workflow).

As a dual-platform implementation partner, Flectic helps SMEs in Canada, the UK, and the USA pick the right approval stack for their actual processes — not the vendor's preferred one — and our AI-accelerated delivery model is designed to deliver up to 3x faster than a traditional waterfall ERP rollout.

Frequently asked questions