Covering an Absent Approver: Delegate Authority, Not Someone’s Login

When an approver is away, give an authorised substitute an explicit, limited grant rather than sharing the absent person's login. A task reassignment says who should work next. Approval delegation says who may exercise a particular decision right. Your workflow app needs to distinguish the two.

Start with the business rule: which decisions can be delegated, by whom, to whom and for how long? This is a software specification, not a legal determination of signing authority. Have the appropriate people approve the underlying authority and any employment, financial or contractual implications.

Scope the grant, not just the replacement person

A hypothetical purchasing team may need cover for routine requisitions during a manager's absence. Does that cover one pending request, every request in the manager's queue or only an agreed class of purchases? Does a value limit still apply? Write the boundary before adding a substitute field.

The Odoo 19 Studio approval-rule guide provides a concrete warning about scope. Its documented delegation option is available only to users listed in the Approvers field, and delegates approval rights for all records to one or several users. Do not assume that selecting a substitute means a one-request exception or that every member of an approver group can use that option.

If your custom app needs narrower coverage, commission and test it explicitly. The product example does not establish your desired transaction limit, department restriction or exclusion of sensitive decisions.

Make the end of cover an actual rule

Odoo's documented Until field controls how long the delegate has approval rights; leaving it empty gives those rights indefinitely. A screen that offers an expiry therefore does not guarantee that a grant is temporary.

For your own application, decide whether temporary cover must have an end, what exact time and time zone apply, and who may extend it. Keep a deliberate permanent grant separate from a holiday-cover shortcut. Show the effective period where the substitute accepts work.

Define early withdrawal and changed circumstances, including a substitute whose account becomes inactive. A cancelled absence should not leave unexplained cover rights behind. These lifecycle rules are recommendations for the commissioned app, not behaviours verified in the cited guide.

Keep the actual decision-maker visible

The substitute should use their own account. Ask the record to distinguish the person who acted, the authority being exercised and the grant that made it permissible. A screen that simply displays the ordinary manager's name can mislead a later reviewer about who made the decision.

Check access separately. Delegating approval should not silently grant unrestricted access to every customer or supplier document. Conversely, a delegate who cannot read the necessary evidence needs a visible resolution path rather than a blind Approve button.

Also decide whether one person can satisfy several required approvals through different grants. Do not let cover accidentally remove a business requirement for independent decisions. The appropriate separation rule depends on your approved process.

Expiry does not undo completed decisions

Separate permission to make a future decision from an approval already recorded. Specify what happens to requests opened before expiry but submitted afterward: the server should evaluate the effective authority at the agreed decision point, not rely on a button that was enabled earlier.

Withdrawal should not silently rewrite history or reverse completed purchasing activity. If a prior decision needs revocation, define that as a separate authorised action with its own consequences. Reconcile pending requests when cover ends so neither the original approver nor the substitute assumes the other still owns them.

Finally, distinguish approval from execution. Odoo documents approving and letting another user perform the action as a separate path. A grant to approve is not automatically a grant to place an order, release funds or send a customer message.

Test both sides of the boundary

Use fictional people and requests in your acceptance criteria. Demonstrate a permitted decision during cover, an excluded request, expiry while a request is open, early withdrawal and a deactivated substitute. Check the saved acting identity and confirm that completed history stays interpretable.

Include a request requiring independent approvals and an approved request whose operational action has not yet happened. For a workflow-app discussion, bring the approved cover rule and one difficult pending case, not anyone's password.

Source boundary

The Odoo 19 documentation, read on 26 October 2026, supports the described delegation eligibility, all-record scope, optional Until behaviour and approval/execution distinction. Narrow grants, server-side expiry checks, history and handback tests are proposed requirements, not certification of product security or legal authority.