Approval rules
A rule says: when this is true of a submitted cart, do that. Everything a customer calls an approval workflow is built from rows of that shape.
Where you find it
Procurement › Approval rules. The list shows name, cost centre, sequence (Seq), condition, effect, approver and whether the rule is active, sorted by sequence. New approval rule opens the form; a row opens the rule for editing.
The parts of a rule
| Field | What it decides |
|---|---|
| Cost centre | Empty: a global rule, measured against the whole cart. Set: the rule measures only the part of the cart booked to that centre, and stays out of the way when the cart books nothing there |
| Condition | Which spend the rule catches |
| Condition parameters | The values the condition needs, as JSON |
| Effect | What happens to spend the rule caught |
| Effect parameters | Optional values for the effect, as JSON |
| Approver type, Approver, Approver role | Who signs, for rules that require approval |
| Sequence | Where this signature sits in the cost centre's chain |
| Show condition | Tells the buyer which condition caught the cart. Its parameters, such as a limit, are never shown |
| Active | Switch a rule off without deleting it |
Conditions
| Condition | Catches the spend when | Parameters |
|---|---|---|
| Always | Always | none |
| Constant limit | The amount is above the limit. Exactly the limit passes | {"limit": 1000} |
| Available budget | The cost centre's budget does not cover the amount. Needs a cost centre | none |
| Personal limit | The buyer's personal limit does not cover the amount | none |
| Contact has role | The buyer holds one of the roles | {"roles": ["requester"]} |
| Contact missing permission | The buyer lacks the permission | {"permission": "place-order"} |
Available budget and Personal limit are asked of the cost-centres side at checkout, and they see money already reserved by waiting requests. If that question cannot be answered, the submission stops instead of passing unchecked.
Effects
| Effect | What happens |
|---|---|
| Pending order (needs approval) | The cart becomes a purchase request and waits for its approvals |
| Prevent | The submit is refused, nothing is created. An optional {"reason": "…"} is returned to the buyer |
| Send email | A notification is recorded on the request, naming the recipient from the effect parameters. Procurement itself sends no mail; it takes a service that reads these records to deliver one |
Every active rule is asked about every submitted cart, and their effects are weighed together. Prevent wins over any number of approvals. Otherwise any Pending order rule makes the cart a purchase request. Send email never changes whether approval is needed. A cart no rule caught becomes an order directly.
How the chain is built
Each Pending order rule that caught the cart contributes one approval. The approvals are grouped by cost centre (global rules form their own group), and within a group they follow the rules' Sequence:
- Only the lowest open step of a group can be decided. Approving it unlocks the next.
- Different cost centres are decided in parallel. A cart booking to
4711and4800waits on both chains at once, independently. - The request is approved when every step in every group is approved.
- One decline ends the whole request, whatever the other chains say.
Give rules on the same cost centre different sequence numbers. Two rules with the same number produce two steps whose order is not defined.
Value bands
The standard shape is one Constant limit rule per band, each with Pending order as the effect, on the same cost centre (or both global):
| Rule | Condition parameters | Sequence | Approver |
|---|---|---|---|
| Over €1,000 | {"limit": 1000} | 10 | Default (accountable contact) |
| Over €10,000 | {"limit": 10000} | 20 | Contact: the managing director |
A €12,000 cart is caught by both, so the accountable contact signs first and the managing director second. A €4,000 cart is caught by the first only. Write the bands as "over X", never as "between X and Y": the €12,000 order needs the first signature too.
Who approves
| Approver type | Who may decide the step |
|---|---|
| Contact | The named contact, and nobody else |
| Role | A contact holding that role. The form offers Buyer, Approver, Administrator and Requester |
| Default (accountable contact) | The accountable contact of the cost centre the rule names, resolved when the cart is submitted |
In every case the person deciding also needs a role that allows approving: a buyer or requester cannot approve, even when a step names them.
The default approver needs a cost centre with an accountable contact. On a global rule, or a centre with nobody accountable, the step names no one. Any contact whose role allows approving may then decide it, and nobody feels it is theirs. Name a contact or a role on global rules.
There is no deputy and no time-based escalation on a rule. Cover for absence is designed in: a Role approver is anyone holding the role, so two or three approvers share one queue. And an administrator can always clear a stuck request in the Cockpit with Super-approve or end it with Cancel request (see Approvals that get stuck).
Product-group and category rules
There is no product condition on a rule. Express it through the cost centre:
- Restrict a cost centre so that the category in question can only be booked to it (see Cost centres).
- Scope the rule to that cost centre.
"Every purchase of Arbeitsschutz needs the safety officer" becomes: a category
restriction pointing safety equipment at 9200, plus an Always rule on 9200
with the safety officer as approver. The allocation and the authority stay one
decision instead of two that can disagree.
The approval gate
The procurement setting Approval gate decides whether rules are applied at all. Booking account (the default) measures every submitted cart against the rules. No approval switches them off: every cart becomes an order and its budget is booked, and no rule can hold, refuse or notify. Requests already waiting are decided as before.
Configure them
- Open Procurement › Approval rules and choose New approval rule, once per row of the table you wrote.
- Leave Cost centre empty for a company-wide rule, or pick the centre.
- Set the condition and its parameters.
- Set the effect. Pending order for anything that should still be possible; Prevent only where an overrun is genuinely forbidden.
- Choose the approver type. On centre rules, Default keeps the rule valid when people change, because it follows the accountable contact.
- Set the sequence, with gaps (10, 20, 30) so a step can be slotted in later.
- Tick Show condition if the buyer should be told which policy caught the cart.
Rules apply to carts submitted after the change. A request that is already waiting keeps the steps it was given, and correcting its lines does not re-run the rules.
What to check
Test three carts as a buyer at that customer, not as yourself:
- Under every threshold: an order is created directly. No request appears.
- Over one threshold: under Procurement › Purchase requests a request appears with status Pending. Its Approvals tab lists the steps, approver and sequence you expect, and the budget shows the amount as reserved.
- Over a Prevent rule: the submit is refused with the reason you wrote, and nothing is created.
If a cart that should have been caught went through, check the rule's cost centre: a centre rule ignores lines booked elsewhere.
Next
- Buyer spend limits: the per-person ceiling.
- The approver's path: what the rules produce.