Approval models
There are four approval shapes in B2B, and almost every customer's policy is one of them or a combination. Recognising which one you are being asked for saves a configuration project.
The vocabulary first
An approval model is built from three pieces, and they stay separate all the way down into the configuration:
- A condition — what has to be true for the rule to fire. A value threshold, a budget check, a personal limit, a role, or always.
- An effect — what happens when it does. Route the cart to a human, refuse it outright, or notify somebody.
- A scope — whether the rule applies to one cost centre or to everything.
Almost every argument about approval workflows is really an argument about one of those three, and separating them ends most of them.
Model 1: single-step by value
The commonest policy in the Mittelstand and the right default. One threshold, one approver.
Anything over €1,000 goes to the Werkstattleiter.
The condition is a constant limit. Under it, nothing happens — the order is placed. Over it, one person signs.
Fits: companies up to roughly 100 people, or a single site with one obvious authority. Most customers should start here even if their written policy is richer, because a policy nobody has operated yet is a guess.
Watch for: the threshold set too low. €250 in a workshop that orders consumables daily produces the ten-approvals-a-day problem and the control dies of exhaustion within a quarter. Set it where it catches the orders somebody would actually want to see.
Model 2: multi-step chains
Two or more signatures, in sequence, by value band.
| Order value | Signatures needed |
|---|---|
| under €1,000 | none |
| €1,000 – €10,000 | Werkstattleiter |
| over €10,000 | Werkstattleiter, then Geschäftsführung |
The second step only starts when the first has approved. That ordering matters: the managing director should not be looking at requests the site manager has already decided to refuse.
This is expressed as bands, not steps. Each band is its own rule with its own condition and its own approver. There is no separate "chain" object to build — the chain is what emerges when several rules match the same request and their approvals are collected in value order.
Fits: 100–1,000 people, or any company with an insurer or a bank imposing a dual-signature threshold. In German practice a Vier-Augen-Prinzip clause above a fixed amount is common and is exactly this model.
Watch for: a chain where every level has a ceiling. If the top approver's limit is €25,000 and a €28,000 spindle arrives, the request has nowhere to go and sits forever. Somebody at the top must be unlimited.
Model 3: parallel approvals
Two people must both decide, and neither waits for the other.
A capital purchase needs the cost-centre owner and the controller.
Both are notified at once, both hold an open decision, and the request only becomes an order when both have approved. Either one rejecting ends it immediately — there is no point asking the second person about a request the first has already refused.
Parallel exists because the two approvers are answering different questions. The cost-centre owner is asked do we need this? The controller is asked does this belong in this budget line this year? Sequencing them adds a day and improves nothing.
Fits: larger customers, and any purchase where a technical and a financial approval are genuinely independent.
Watch for: using parallel where you meant informational. If the controller never rejects anything, they do not want an approval — they want a notification. Give them one and take them off the critical path.
Model 4: deputies and escalation
Not a model on its own, but the thing that makes the other three survive holidays. Two mechanisms, and they are different:
A deputy is a standing arrangement. A cost centre has an owner and may have deputies; a deputy may decide anything the owner may decide, and the decision is recorded under the deputy's own name, not the owner's. This is the difference between a deputy and a shared password, and it is the entire audit argument for having the feature.
An escalation is time-based. A request that has sat undecided for a defined period is passed upward or sideways — first as a reminder, then by moving the open decision to the next person in the band. The trigger is elapsed time, not a value, so it needs the platform's scheduler rather than the checkout path.
Escalation is the single most requested feature after budgets, and for a predictable reason: the first time a €40,000 machine order waits nine days because one person was in Südtirol, the customer's purchasing department stops defending the shop internally.
Which model fits which customer
| Customer | Model | Why |
|---|---|---|
| Under 50 people, one site | Single-step by value, one threshold | More structure than this will not be maintained |
| 50–300, several departments | Single-step per cost centre, cost-centre owner approves | Authority follows the budget, which is how they already think |
| 300–1,000, formal controlling | Chains with two or three bands, deputies mandatory | There is an insurer or an auditor behind the second signature |
| Over 1,000, own procurement system | None of the above | Their workflow lives in SAP Ariba, Coupa or Onventis. Use punchout and never rebuild it |
That last row is the one people skip. For a large buyer, reproducing their approval matrix in your shop is a project with no end — their policy changes twice a year and yours would have to follow. Punchout hands the cart back to their system as a requisition and every approval happens on their side.
How this works in the Revenue Cloud
Rules are rows, not code. Each rule in the Approval Workflows app carries a condition, an effect, and an optional cost centre.
Conditions available today:
| Condition | Fires when | Evaluated by |
|---|---|---|
always | Every submit | Approval Workflows |
constantLimit | The cart value exceeds a fixed amount | Approval Workflows |
| role / permission | The buyer holds — or lacks — a given role or permission | Approval Workflows |
availableBudget | The line would exceed what is left on the cost centre | Cost Centers |
personalLimit | The value exceeds this contact's own ceiling | Cost Centers |
Effects:
| Effect | Result |
|---|---|
pendingOrder | A purchase request is created and routed for signature |
prevent | The submit is refused. No request, no order |
sendEmail | Somebody is told. The submit continues |
prevent is the hard stop and pendingOrder is the soft one — that distinction
is what "hard limit" and "soft limit" mean everywhere else in this area, and it
is a property of the effect, not of the budget.
A rule with no cost centre is global: it applies to every submit, which is how a plain "everything over €1,000 needs a signature" policy is expressed without modelling a single cost centre. A rule scoped to a cost centre only applies to lines booked against it, which is how per-department authority is expressed.
Chains and parallel steps are not separate objects. Several rules can fire on one submit; each produces an open decision, and the request becomes an order when all of them are settled.
Next
- Purchase requests vs. orders — what exists between the cart and the order.
- Approval rules — build the model you picked.