The approver's path: approve or decline
The approver is the person who decides whether your customer keeps using the shop. They are usually busy, usually not the person who chose the article, and they expect a decision to take a minute. This article is what happens to a purchase request between submission and order, and what you can do from the Cockpit when it stalls.
Where a request waits
Every request is under Procurement › Purchase requests. Open one, and the Approvals tab lists what it waits for, one row per approval:
| Column | Tells you |
|---|---|
| Cost centre | Which cost centre's chain the approval belongs to. Empty for the global chain |
| Step | Its place in that chain, from the rule's sequence |
| Approver type, Approver contact, Approver role | Whose decision it is: one contact, anyone holding a role, or the cost centre's accountable contact |
| Status | Pending, Approved or Declined |
| Decided by, Decided, Reason | Who decided, when, and why |
There is no separate approval inbox in the Cockpit; you reach every approval through its request. A click on a row opens that approval with the rule it came from. Its Approve and Decline buttons are refused for Cockpit users with a permission error (403): a single step is decided by its approver (see below).
How the decision moves
- Within one cost centre, in order. Only the lowest open step of a chain can be decided. Deciding step 1 while step 0 is still open is refused. Approving step 0 opens step 1.
- Across cost centres, in parallel. Each cost centre's chain moves on its own. Nobody waits for another cost centre's approver.
- One decline ends everything. A decline on any step of any chain ends the whole request as Declined, keeps the reason, and returns the reserved budget. Other approvals still open can no longer be decided.
- The last approval places the order. When nothing is open any more, the request turns Approved, the order is placed and linked, and the budget reservation is confirmed against it. The request ends as Ordered.
If the order cannot be placed at that moment, for instance because a service is briefly unavailable, the approval still stands. The request stays Approved and the hourly reconciliation places the order, exactly once.
Who may decide a step
The procurement app checks every decision against the contact taking it:
| The approval names | Who may decide |
|---|---|
| A contact | That contact, if their role allows approving |
| A role | Any contact holding that role, if the role allows approving |
| Default (accountable contact) | The cost centre's accountable contact, looked up when the cart was submitted |
An approval still showing Default after submission found no accountable contact on its cost centre; any contact whose role allows approving may then decide it.
A decision on a single step belongs to the approver it names. It reaches the procurement app through its API from a system acting for that approver, typically your shop, and the platform states which contact is deciding. The app records that contact as Decided by; what the request itself claims about who is deciding is ignored, so nobody can decide in someone else's name. A decision on one step carries no email, and neither the next approver nor the buyer is told by the apps.
What you can do from the Cockpit
In the Cockpit you act for the back office, not as one of the customer's contacts. So you do not decide individual steps. You have the two overrides, both on the purchase request itself:
| Action | Effect | When to use it |
|---|---|---|
| Super-approve | Clears every open approval on every chain at once, records the override on each, and places the order | The approver is away, the customer's administrator has asked you to push it through, and someone at the customer owns that decision |
| Cancel request | Ends a pending request as Cancelled and returns its reserved budget | The buyer no longer wants it, or the request was submitted wrong |
Both act on a Pending request. The same two overrides are open to the customer's own organisation administrator in the shop, and cancelling is also open to the buyer who submitted the request.
What the approvals do not do
The procurement app has no delegation, no deputies, no escalation and no expiry. A request waits for the approver its rule named until it is decided or cancelled. The ways around an absence are in the rules: name a role rather than a person where two people can sign, or change the cost centre's accountable contact before the holiday, since that is looked up when a cart is submitted, not later. See Approval models.
Approving does not change the request either. The approver signs for the lines as they are. If a pending request's lines are corrected later, totals and the reservation follow, but the rules are not run again and approvals already given stay given.
What to check
Before a customer goes live, run one request through every step with the real approvers:
- Submit a cart that matches two rules on the same cost centre. The Approvals tab shows two rows on that cost centre, steps 0 and 1.
- Have the step-0 approver approve. Step 0 shows Approved with their name under Decided by; the request is still Pending.
- Have the step-1 approver decline with a reason. The request is Declined, the reason is on it, and the cost centre's ledger shows a Withdrawal entry.
- Repeat with an approval, and check the request ends Ordered with a link to the order.
Next
- Reading the budget ledger — what every decision did to the money.
- Approvals that get stuck — when nobody decides.