Approval Gates: Approve Right in the Record

by Sveltware Solutions

$ 455.90

In-App Purchases

v 19.0 Third Party

You bought this module and need support? Click here!

Approval Gates

Approve Right in the Record

odoo@sveltware.com

By Sveltware Solutions

Your approval policy, enforced where the work happens.

Bind an approval workflow to any Odoo document, no code required. The risky action is gated server-side until the route signs off, a sensitive field change is withheld until it is approved, and amounts walk up the management chain by each manager's authority limit. Every decision lands in an append-only ledger, so who approved what, when and why is never a mystery.

Coverage

Any Odoo Document

On a standard Odoo 19 install that is over 120 guardable actions and thousands of approvable fields. A module installed next year works the same day.

Enforcement

Server-Side Gates

The hold sits at the method itself, so it covers buttons, list actions, imports and API calls alike. Not a view trick.

Audit

Append-Only Ledger

Every decision recorded with its author and moment, and submitted content frozen so a signature never outlives what it signed.

Hold Any Button

Confirm Order stays right where it is. It just will not fire until the route signs off.

Point a trigger at the button and it starts asking for approval instead of running. Nobody has to be told a new place to click, and nobody loses a button they used yesterday.

Buttons customers gate on day one

Confirm Order Validate Create Invoice Post Send by Email Mark as Done Cancel and 120+ across the database

Hiding the button is not the same thing. Access rights decide who sees a button. A hold decides whether the work behind it may happen at all, which is the question an approval is actually asking.

Live Demo · Try Before You Buy

Try to confirm a purchase order you are not allowed to confirm.

A company caught mid-story: routes staffed, triggers armed, requests already waiting. Sign in as the buyer and the order refuses to confirm. Sign in as the approver and release it.

1 Open the demo 2 Sign in as the buyer 3 Press Confirm Order

https://workflow.sveltware.com/odoo

Click to select, copy into a new tab. Sign-in details are on the demo's home page.

The Overview screen with a card for each of the thirteen approval policies, each showing its rule, the people on its route and how many requests are in review, with one route open in a window beside them

Overview · Every policy on one screen, with its rule, its approvers and what is waiting on it right now

A draft vendor bill with the approval banner at the top of the form, showing whose turn it is, who signs after them, and Approve and Reject sitting right there

Approve Where You Work · The banner sits on the document itself, showing the route so far and putting the decision one click away

Confirming the same bill is refused with a message naming both approvers it is still waiting on

Server-Side Gate · Blocks document actions across buttons, imports, and API calls until approved

A vendor bank account waiting on the Chief Accountant, the banner naming the old account number and the new one, and the account field below still holding the old number

Held, Not Applied · The banner names the change and the old value stays on the record, so a redirected account cannot be paid while it waits

Approving the same bank account change asks the approver for their password before the decision is recorded

Signed, Not Clicked · Turn on password confirmation where it matters, so an unattended screen cannot approve a payment

A purchase order held for approval, with the route open in a movable window beside it showing the buyer, the mandatory approver whose turn it is, and the approved end state

The Route Beside the Work · Open the live route from the banner in a window that moves aside, so the document stays readable

All Requests list view showing status badges and activity warnings across requests

Request Management · Track every active approval, status, and pending activity in one place

Approval Triggers list view showing 9 bindings across document models

Approval Triggers · Bind workflows to any Odoo model with action gates or field-hold controls

Approval Trigger form for purchase orders from 5,000, showing the document model, the condition, the held action and the resume setting

Trigger Setup · Pick the document, write the condition, name the action to hold. No code, no server restart

The Payment Release policy in configuration, grouped into who approves, what counts as approved, what happens when nobody acts, and which fields the request form asks for, with re-enter password to approve ticked

Policy in Plain Settings · Quorum, sequence, escalation, password signing and the request form itself, all as tick boxes

Workflows list showing thirteen approval policies with the rule of each one written out in plain words

Workflow Policy Catalog · Manage all enterprise approval policies, rules, and authority limits

The Forward Approval dialog on a held price change, asking who takes the seat over and why, with a note that the seat keeps its order, its mandatory flag and its share of the quorum

Forward a Seat · Hand your approval to the right person, with the reason on the record. The route keeps its rules

The History tab of a contract review request, showing a forwarded seat with both names and the reason it was handed over, above the line recording who submitted it

Audit Trail · Every decision on the record: who, when, and why. Append-only, written by the engine alone

# The approval holds the document itself

A signature collected beside the work protects nothing: the document moves anyway. Here the workflow takes custody of it.

You point an Approval Trigger at any document model and set the conditions. While a request is open, the guarded action cannot run. Approval releases it, and finishes the job if you want: the purchase order confirms itself.

Approvers never hunt for work. The decision waits on the document they already know, and the ledger answers the auditor who asks in January what happened in March.

Any Document Field Approval Authority Limits

Nothing to code

Three form fields, the document, the condition and the action to hold, combine into one armed trigger, with zero lines of code written.

The approval loop, closed end to end

The approval loop: a matching document opens a request and holds the guarded action, the route signs off, then the gate releases and the held action can run itself. A rejection leaves the document untouched, and every step lands in the append-only ledger.

01 · Trigger

A document matching your conditions is created, updated or pushed toward a guarded action. A request opens and the action holds.

02 · Decide

The route decides: in parallel or in sequence, by quorum or unanimously, with mandatory approvers who can never be skipped.

03 · Resume

Approval releases the gate and can run the held action automatically. A rejection is final, and a withheld field change is simply never applied.

# Key Features & Capabilities

Authority Limits & Escalation

Give each employee an approval limit. The route walks the management chain until it reaches someone whose limit covers the amount, and stops there.

A 32,000 request from Rita, who has no approval limit, passes Sam, whose limit of 10,000 does not cover it, and stops at Diana, whose 50,000 limit does, so she signs. Below: a request within your own limit is approved on submission, and a seat that stays silent escalates to their manager.

Routes That Match Policy

Sequential or parallel, a quorum, mandatory seats, a threshold per seat, the requester's manager.

Bind on Any Document

Orders, expenses, journal entries, scraps, contacts: anything with a model, on your conditions.

Live Diagram & Simulator

Every route draws itself. The simulator answers who would sign a given amount, before anyone submits.

Audit-Grade by Construction

A ledger nobody can edit, and content frozen the moment it is submitted, so a signature holds.

Sign With a Password

Approving asks for the approver's password, so an unlocked screen is never a signature.

Forward to Someone Else

Hand a seat to someone else with a reason. It keeps its place in the route; the ledger keeps both names.

Field Approval

Mark a field as held and editing it opens a request instead of saving. Built for price changes and vendor bank accounts, the classic fraud doors.

Editing a held list price from 1,200 to 1,350 holds the save and opens a request while the stored price stays 1,200. Approved, the new price is written and goes live; rejected, there is nothing to undo because it stayed 1,200.

# Decisions where the work already is

Approvers should not learn a new app to say yes. Four screens carry the decision, and every one of them goes through the same audited door.

Document form

A banner on the held document names what is pending and, when it is your turn, carries Approve and Reject.

Activity inbox

The review lands as an activity on the business document, so it shows up in the systray and the activity columns you already watch.

List views

Decide straight from the activity popover in any list, without opening a single record.

Request form

The full picture: route, held changes, diagram, history, and Send Back for Revision when the answer is "yes, but fix this first".

Standalone requests work too: not every approval needs a document. Budget sign-offs and policy exceptions run the same routes with the same ledger.

# The route belongs to the policy, not the requester

An approval matrix is only a control if the person being controlled cannot edit it. The approver board is editable in draft, because adding a second pair of eyes is useful. What it cannot do is remove the policy.

A policy route with two mandatory approvers, edited in draft to delete one and soften the other, is restored at submission: the deleted approver returns and the mandatory flag hardens again, while approvers added on top are kept.

Content freezes

Once submitted, the amount, the subject and the attachments stop being editable. A signature never outlives what it signed.

The amount re-checks

Raise the total mid-flight and the route recomputes, so a higher tier cannot be skipped by editing after submission.

Changing your mind

An approver can revoke a decision while the request runs, and the revocation is recorded like any other. The ledger loses nothing.

The legitimate ways back exist and are explicit: Reset to draft and Send Back for Revision, both of which clear the votes already cast.

# Start from real policies, not a blank screen

The companion Real-World Policy Pack module ships twelve approval policies distilled from actual finance and operations practice. It installs as a working setup, not as staged demo theater: on a real database it stays quiet until you arm it yourself.

The pack ships twelve policies, nine of them bound to documents. On a real database the policies and thresholds install with every trigger disabled, and two human acts per policy, staffing the route and pressing Enable, turn it into a live control. Installed with demo data instead, it brings a sample company of fourteen people with routes staffed, triggers armed and requests already waiting.

PO Approval Vendor Bank Change Price Change CAPEX Expenses + 7 more

Every policy in the pack is plain configuration you can read, edit or delete: nothing in it is hard-coded, and each one is a documented control practice rather than an invented example.

Which documents can it put under approval?

Any model in your database, standard or custom, without writing code. An Approval Trigger names the document, the conditions (amount above a threshold, a specific vendor category, whatever a filter can express) and optionally the action to guard: confirm, validate, post. The trigger also keeps watching: if the document leaves the conditions the request dissolves, and if the amount changes midflight the route is re-checked, so nobody slips under a threshold by editing after submission.

Does it work on Odoo Community, Enterprise, and Odoo.sh?

Yes to all three. It is a standard Odoo 19 module with no external service dependencies: nothing to host, nothing to call out to, no account to create. Community and Enterprise are both supported, and on Odoo.sh or any hosted setup it installs like any other module. Multi-company setups are supported as well: workflows, triggers, requests and ledger entries each carry their company, so one database can run different approval policies per company without them seeing each other's requests. It was designed from scratch as a policy engine, so it goes where simple approval checklists stop: field-level approval, per-employee authority limits with escalation, a live route diagram, a simulator, and gates that hold server-side rather than hiding a button.

How exactly does Field Approval work, and what are its limits?

When someone edits a held field in the form, the edit is intercepted before it reaches the database: the widget snaps back to the stored value and a dialog sends the old and new value into an approval request. Approval writes the new value; rejection writes nothing, because nothing was ever changed. The value in use is always an approved value.

Honest boundary: this control governs people editing through the form. Server automations, imports and API scripts write directly, by design, because a scheduled pricelist update is not a person asking permission. If you need machine writes gated too, guard the action that commits them with a standard trigger.

Does it modify my documents or Odoo's standard behavior?

No schema changes on your business documents and no rewritten core screens. Gates attach at runtime through the framework's own extension mechanism, only for the triggers you enable, and detach cleanly when you disable a trigger or uninstall the app. Your documents and their history stay exactly as they are.

Do approvals always need a source document?

No. Requests also stand on their own for approvals that live outside any record: budget sign-offs, travel, policy exceptions. The request form carries the details, amounts, time periods, contacts and attachments your workflow asks for, with required fields enforced at submission, plus automatic reference numbering per workflow if you want it.

Can it hold payments made through the Register Payment wizard?

Payment approval is built for draft payments, the way treasury teams that separate preparation from release already work: create the payment under Payments, the route signs off, posting is released. The Register Payment wizard is a different shape: one click creates the payment and posts it, inside a single transaction. Holding the posting there leaves a draft payment behind while the wizard reports success, which is a worse answer than a clean queue of approvals. If your process runs entirely through that wizard, tell us before you buy and we will say plainly whether this fits.

What support and updates are included?

Every purchase includes three months of support directly from the author, starting on your purchase date. It covers installation help, configuration questions, fixes for any genuine defect, and help mapping your own approval matrix onto the engine. Fixes and updates within your Odoo 19 major version are included for the same period, and support is handled by the people who built the module, by email. Two things sit outside it, and we always tell you which is which before any work starts: custom development beyond the module's scope, and upgrades to a future major Odoo version.

What if it does not work out for my company?

Then you get your money back. Every purchase carries a 30-day guarantee: run it on your real policies, your real documents and your real approvers, and if it does not do what this page says and we cannot make it right, we refund the purchase in full. One email, no forms. We can afford this because the live demo and the free policy pack let you verify the hard parts before you spend anything.

What happens to my database if I uninstall it?

It lets go cleanly, and that is deliberate: an app that holds your documents must be able to stop holding them. Uninstalling releases every gate it placed, removes the automation rules it generated, and drops its own tables. Your purchase orders, bills and payments keep working exactly as they did before it was installed, with no leftover blocks and no schema changes to unwind. We test that path on a full setup with every trigger armed, not just on paper.

# Who We Are

Sveltware Solutions is a small studio building premium extensions for the Odoo backend. We work close to the metal, its OwlJS layer, rendering pipeline, and extension points, so we can change how Odoo feels without touching what keeps it stable: we build on the framework's own hooks, never override its internals.

Not one add-on but a connected ecosystem, themes, list and kanban tools, faceted search, printing, activity, and AI, under one design language. Every module is plug-and-play: zero config, no schema changes, clean uninstall, and proven on production-scale data.

It is built to be looked at, too: Apple-grade spacing, a flat-premium finish, strict WCAG 2.2. Our standard is effectiveness first, every module earns its place by making real work faster, and so does our support, replies in minutes, not a next-day queue.

Sveltware Solutions

Crafting pixel-perfect, zero-configuration enhancements for Odoo environments.

# How We Build

Six standards every Sveltware module must pass before it ships:

01 · Architecture

Extend, Never Override

We hook into Odoo's official extension points instead of monkey-patching internals. Standard views, workflows, and other modules keep working exactly as before.

02 · Data Safety

Fully Reversible

No schema rewrites, no data migration, no leftovers. Removing one of our modules returns your database to exactly the state it was in before.

03 · Onboarding

Zero Configuration

Install and use. Our modules read your existing setup, attributes, views, and access rights, instead of asking you to rebuild it in a settings screen.

04 · Performance

Fast on Real Data

We test against large, production-shaped databases, not demo data. Indexed domains, client-side caching, and lazy loading are the default, not an afterthought.

05 · Design

Native and Accessible

Every interface follows Odoo's native design language and meets WCAG 2.2: full keyboard support, real focus states, and contrast that holds up in light and dark mode.

06 · Longevity

Maintained Across Versions

We track Odoo's release cycle and update our suite for each major version, so upgrading Odoo never means abandoning the tools your team relies on.

# The Sveltware App Suite

One family of modules, designed to work seamlessly together. Click any app to open it on the Odoo Apps store in a new tab.

Flagship · Backend Themes

Omux & Lavend · Backend with Agentic AI

A complete redesign of the Odoo backend, available as Omux or Lavend, each running on both Community and Enterprise: dual sidebars, custom presets, hybrid start menus, dark/light modes, and WCAG 2.2 compliance, with agentic AI woven in.

Omux Backend Lavend Backend

Browse every Sveltware module and theme on the Odoo Apps store, always up to date.

Browse all apps

Availability	Odoo Online Odoo.sh On Premise
Odoo Apps Dependencies	• Discuss (mail) • Employees (hr)
Lines of code	4585
Technical Name	`svn_workflow`
License	OPL-1
Website	https://www.linkedin.com/in/sveltware

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

The author can leave a single reply to each comment.
This section is meant to ask simple questions or leave a rating. Every report of a problem experienced while using the module should be addressed to the author directly (refer to the following point).
If you want to start a discussion with the author or have a question related to your purchase, please use the support page.