Approval models
Most customers' approval policies come in a handful of shapes, and almost every written policy is one of them or a combination. Recognising which one you are being asked for saves a configuration project, and tells you early whether the approval rules can express it.
The vocabulary first
An approval rule is built from four pieces, and they stay separate all the way down into the configuration:
- A condition: what has to be true for the rule to match. A fixed amount, the cost centre's remaining budget, the buyer's personal limit, a role the buyer holds, a permission the buyer lacks, or always.
- An effect: what happens when it does. Hold the cart for approval, refuse it outright, or record that somebody should be told.
- A scope: whether the rule applies to one cost centre or to the whole cart.
- An approver and a sequence: who signs, and in which position of that cost centre's chain.
Almost every argument about approval workflows is really an argument about one of those four, 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.
One rule: condition Constant limit with a limit of 1,000, effect Pending order (needs approval), approver the Werkstattleiter. A cart of exactly €1,000 does not match; €1,000.01 does. Under the limit, the order is placed.
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 ten approvals a day, and the control dies of exhaustion within a quarter. Set it where it catches the orders somebody would actually want to see.
Model 2: chains in sequence
Two or more signatures, one after the other.
| Order value | Signatures needed |
|---|---|
| up to €1,000 | none |
| €1,000 – €10,000 | Werkstattleiter |
| over €10,000 | Werkstattleiter, then Geschäftsführung |
There is no separate "chain" object. The chain is what you get when several rules on the same cost centre match one cart. Each matching rule with the effect Pending order creates one approval, and the approvals of one cost centre are worked through by the rule's sequence number: only the lowest open one can be decided, and approving it opens the next.
The table above is two rules on the same cost centre:
| Rule | Condition | Sequence | Approver |
|---|---|---|---|
| Werkstatt ab 1.000 | Constant limit 1,000 | 0 | Werkstattleiter |
| Werkstatt ab 10.000 | Constant limit 10,000 | 1 | Geschäftsführung |
A €5,000 cart matches only the first rule and needs one signature. A €12,000 cart matches both and needs two, in sequence order. The value bands come from the conditions; the order of signatures comes from the sequence, never from the amounts. Give each rule on a cost centre its own sequence number, so the order is never left to chance.
Rules with no cost centre form one chain of their own and are measured against the whole cart.
Fits: 100–1,000 people, or any company with an insurer or a bank imposing a dual-signature threshold. A Vier-Augen-Prinzip clause above a fixed amount is common in German practice and is exactly this model.
Watch for: one decline ends the whole request, at any step. The Geschäftsführung saying no after the Werkstattleiter said yes leaves nothing to order, and the buyer starts again from a cart.
Model 3: parallel cost centres
Parallel approval exists in one form: across cost centres. A cart with
lines on 4711 (Werkstatt) and KST-2200 (Instandhaltung) carries two chains,
one per cost centre, and neither waits for the other. Each cost-centre owner
decides their own share. The request becomes an order only when every approval
on every chain is given, and a single decline on either side ends it.
That is the right shape when the two approvers answer different questions about different money. The Werkstatt owner is asked about the Werkstatt's budget; the Instandhaltung owner about theirs. Sequencing them would add a day and improve nothing.
Two approvers on the same cost centre always form a chain. If a customer asks for "the cost-centre owner and the controller, at the same time", the nearest you can offer is the two in sequence, or the controller informed rather than asked (below).
Watch for: asking for an approval where a notification is meant. If the controller never declines anything, they do not want an approval. A rule with the effect Send email records that they should be told and never holds the cart. The procurement app sends no mail itself: the notification is written to the request's history and published as an event, so delivering it is a matter for the system that picks it up.
Holidays: plan for them in the rules
The approval rules have no deputies, no escalation and no expiry. A request waits for the approver it names until somebody decides it. That makes the choice of approver type the holiday plan:
| Approver type | Who may decide | Survives a holiday? |
|---|---|---|
| Contact | Exactly that contact | No. The request waits for them |
| Role | Any contact holding the named role | Yes, if more than one person holds it |
| Default (accountable contact) | The cost centre's accountable contact, looked up when the cart is submitted | Only if you change the accountable contact before the request is submitted |
And there is the override: an administrator can clear every open approval on a request at once (Super-approve) or cancel a waiting request. In the Cockpit both sit on the purchase request. See The approver's path.
Which model fits which customer
| Customer | Model | Why |
|---|---|---|
| Under 50 people, one site | Single step by value, one global rule | More structure than this will not be maintained |
| 50–300, several departments | Single step per cost centre, approver Default (the accountable contact) | Authority follows the budget, which is how they already think |
| 300–1,000, formal controlling | Chains of two or three rules per cost centre, approvers by role | 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 leave approval to their system |
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, and every approval happens on their side.
How this works in the Revenue Cloud
Rules are rows, not code. You maintain them under Procurement › Approval rules. Each rule carries a name, an optional cost centre, a sequence, a condition with its parameters, an effect with its parameters, an approver, a Show condition switch and an Active switch.
Conditions:
| Condition | Matches when | Asked of |
|---|---|---|
| Always | Every cart the rule applies to | procurement |
| Constant limit | The amount is above a fixed limit | procurement |
| Contact has role | The buyer holds one of the named roles | procurement |
| Contact missing permission | The buyer lacks one of the named permissions | procurement |
| Available budget | The cost centre's share is more than its remaining budget. Only on a rule with a cost centre | cost-centers |
| Personal limit | The amount is more than the buyer's personal limit. Whole cart, or one cost centre's share | cost-centers |
A rule with a cost centre measures only that centre's share of the cart and does nothing when the cart books nothing to it. A rule without one measures the whole cart.
Effects:
| Effect | Result |
|---|---|
| Pending order (needs approval) | The cart becomes a purchase request with one approval for this rule |
| Prevent | The cart is refused with the rule's reason. No request, no order |
| Send email | A notification is recorded, naming who should hear about it. Whether the cart needs approval is unchanged |
When several rules match, Prevent wins over everything, then Pending order; Send email never changes the outcome. A notification is recorded only for a cart that becomes a purchase request.
Prevent is the hard stop and Pending order the soft one. "Hard limit" and "soft limit" mean exactly that everywhere in this area: a property of the rule's effect, not of the budget.
Show condition lets the shop tell the buyer which kind of condition caught the cart, for example Personal limit. The parameters, such as the amount, are never passed on.
Next
- Purchase requests vs. orders — what exists between the cart and the order.
- Approval rules — build the model you picked.