> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/classes/admin/approvals.md). # Approvals {% @arcade/embed url="" flowId="vE8CgaeYRyZGuPMkXg9g" %} Approvals is the point where a request becomes binding. Everything in the list is prepared and visible, and none of it is executed until someone decides. Placing the order is that moment, which is also why the terms have to be accepted first: approving is not an opinion, it commits your company to the conditions behind the offer. The decision is rarely only yes or no. This is also where you decide whether to order at all, because a device may already be sitting in your warehouse. The person who requested it cannot see stock. You can, and using it is usually faster and cheaper than a new order. Swap and return requests land in the same list, marked as changes rather than new requests. The service already exists and the request modifies it. Same flow, different consequence. If this list stays empty, check your approval mode before you assume nothing is happening. With Automatic Approval there is no decision step, and requests go straight into the approved order requests. ### More than yes or no: the Actions menu Approving as it comes is the common case, not the only one. Open a request and the Actions menu lets you adjust it first. This is the last point where changing something is free. Once the order is placed, the same change means contacting a supplier or correcting a delivery that is already on its way.
**Change delivery date** decides when it should arrive rather than whether it is approved. Useful for a new starter who begins in three weeks: approve now so the budget and the process are settled, and have the device turn up shortly before the first day instead of sitting in an office for a month. **Change delivery address** overrides the address that came with the request. The requester picked from what they knew, you often know more: they are moving to another site, the office is closed that week, or a home delivery makes more sense than one more parcel at reception. **Reserve for group** approves the request without pinning it to one person yet. The units are held for a group, an apprentice intake or a rollout wave, so nobody else takes them while the names are still being sorted out. **Reject** ends the request. The requester is notified, and nothing is ordered. Worth pairing with a short reason, because a rejection without one usually comes back as the same request a week later. ### Read more {% content-ref url="/spaces/sefXXH6Iz8RCwoM5daoW/pages/rotx80IMmeyzdhc0WiSu" %} [Approvals](https://app.gitbook.com/o/tyg0OyVUuxExVkZRRN7N/s/sefXXH6Iz8RCwoM5daoW/main-menu/approvals) {% endcontent-ref %} {% content-ref url="/spaces/sefXXH6Iz8RCwoM5daoW/pages/8TQOQe2k54fiV0ccS2bX" %} [Using Existing Stock Before Ordering](https://app.gitbook.com/o/tyg0OyVUuxExVkZRRN7N/s/sefXXH6Iz8RCwoM5daoW/main-menu/approvals/using-existing-stock-before-ordering) {% endcontent-ref %} {% content-ref url="/spaces/sefXXH6Iz8RCwoM5daoW/pages/97TfADD6obBY8GjPOdTd" %} [Approval settings](https://app.gitbook.com/o/tyg0OyVUuxExVkZRRN7N/s/sefXXH6Iz8RCwoM5daoW/settings/approval-settings) {% endcontent-ref %} ### Next Approved requests have to be delivered. That is [Fulfill internal orders](/classes/admin/fulfill-internal-orders.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://hub.equipme.io/classes/admin/approvals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.