Execution Layer for Odoo

Approvals.

The approvals screens of the Execution Layer: how a risk-classed action stops, what the payload-bound request looks like, who sees what, and what Approve and Deny actually release.

Available now · Odoo 19 Updated 20 September 2026

When an AI call matches a risk class, it does not execute. It stops with APPROVAL_REQUIRED and lands here, bound to the exact payload, waiting for a person. Since version 1.1 that includes AI messaging: for users on the approval level, a Discuss or WhatsApp send waits here too, and the approver reads the actual message body in the preview.

The queue

The approvals queue: a pending payload-bound request showing what was requested, the risk class, who asked, the tool and model, the approvers, the state, the expiry, and Approve and Deny buttons. — Each row: what was requested, under which risk class, by whom, decided by whom, expiring when.

Each row shows what was requested, the risk class that caught it, who asked, the tool and model, the approver or approvers, the state, and when the request expires. Requesters see their own requests; approvers see requests addressed to them; auditors and administrators see all. By default an Odoo activity also reaches the approver, so the queue comes to them.

One request, in full

A single approval request: the Deleting anything risk class, the plain explanation that approving lets the AI client retry exactly this action, the request reference, expiry, approvers, and the redacted preview of exactly what would be executed. — The form shows the exact bound payload under 'What will be executed'. Approving releases exactly this, and nothing else.

The form explains itself in one sentence: the AI client asks to run this tool on this model; approving lets that client retry exactly this action, and anything different will be refused as stale. Below it, the redacted preview shows the exact payload the approval is bound to.

What Approve and Deny actually do

The request is payload-hash-bound. That single fact drives every behavior:

Approve, then the AI retries the identical call: it executes, is verified, receipted, and audited like any other write.
Approve, then the AI retries something different, even slightly: APPROVAL_STALE. An approved “delete these 10 activities” can never be reused to delete anything else.
Deny: the AI gets a structured refusal, and the decision is recorded.
The request expires (24 hours by default, per risk class): the AI must ask again, and the expired request stays on the record.
The approver can be the same user, a specific person, a group, or an activity queue, per risk class; separate-approver routing means the person who asked is not necessarily the person who decides.

Approval is a gate, not a bypass

An approved action still runs through the whole pipeline: preconditions, atomic execution, database read-back, verification, audit. Approval unlocks exactly one payload; it never relaxes anything else.

Every request, decision, and execution in this flow lands in the evidence trail: receipts and history shows where.