--- title: How to route a purchase order for approval url: https://tideswell.xyz/docs/purchasing/approvals description: Turn on approval for a single order, submit it with a note, and approve or refuse from the queue. --- > Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further. # How to route a purchase order for approval Approval is set **per order**, and it is off by default. Turning it on means the order cannot be sent until somebody signs it off. **Approvals** in the sidebar is where the decisions get made. ## Before you start [#before-you-start] Turning approval on needs store write access. Turning it back **off** needs the same standing as granting an approval, otherwise the switch is disabled with a tooltip saying why. That asymmetry is on purpose: anybody can add a check, and only an approver can remove one. Approving or refusing needs the approve permission, per . ## How do you require approval on an order? [#how-do-you-require-approval-on-an-order] Open the order and turn on **Require approval before sending** in the **Properties** panel. It applies to that order alone and changes nothing for anybody else. Use it for the orders where the money warrants a second pair of eyes rather than switching it on everywhere. While a request is in flight you cannot change whether the order needs approval. Withdraw or decide the request first. ## How do you submit one? [#how-do-you-submit-one] Submit it for approval from the same panel, with an optional note for the approver. Write the note. "Covering the eleven-day cover on the merino, revised down from the original" is the difference between a decision and a guess, and the approver sees it on their queue. The order then shows who requested it and when, along with the note. ## How do you approve or refuse? [#how-do-you-approve-or-refuse] From **Approvals**, which lists everything waiting on your decision with the order, its amount, who asked, when, and their note. You can decide straight from the queue or click through to the full order. **Refusing requires a reason**, and a refusal without one is rejected. The reason goes back to the requester and is recorded on the order in red. That is the useful half of a refusal. "No" tells somebody nothing; "no, because we already have eight weeks of cover" tells them what to change. The outcome is recorded on the order either way, and the requester gets a notification. ## Why can I not approve my own order? [#why-can-i-not-approve-my-own-order] Because you cannot approve your own request, and you cannot approve an order you created. This is a business rule rather than a permission, which means **an admin cannot override it**. It is the whole point of an approval: a second person has looked. If you are the only person who could approve, an order you raised can never be approved. The software will not paper over that, and the fix is to give somebody else the approve permission or have them raise the order. Your own requests appear in your queue read-only, with the reason there are no buttons on them: **You raised this** or **You created this record**. ## What happens if two approvers click at once? [#what-happens-if-two-approvers-click-at-once] The second is told it has already been decided. Nothing is double-recorded. ## How do you cover approvals while you are away? [#how-do-you-cover-approvals-while-you-are-away] Set an out-of-office delegation on your account, naming a colleague and an end date. Be aware of what that grants: your delegate can do anything you can do in this workspace, rather than approvals alone. See . It does not exempt anybody from separation of duties. Your delegate still cannot approve their own request. ## What else can be approved? [#what-else-can-be-approved] Purchase orders, and today that is the only thing that appears in the queue. A row whose purchase order has since been deleted reads "Purchase order (deleted)" rather than vanishing, so a queue never quietly loses an item.