Purchase Requests, Routed and Documented

Process automation demonstration

Make
Purchase Approvals
Process Automation

A functional automation built in Make, showing how one purchase request can move from structured intake through manager review, policy-based approval routing, purchase documentation, receipt collection, and final closeout while preserving one Request ID and one continuous tracking record.

The operational problem

Purchasing breaks down when the process lives across email and spreadsheets

In a fragmented purchasing process, employees email requests, managers ask for missing information, approval requirements are applied inconsistently, and records are entered separately into spreadsheets. Supporting documents and receipts can become disconnected from the original request, leaving staff to reconstruct the history manually.

Slide showing the fragmented manual purchasing process in seven steps and the common operational risks: incomplete requests, unclear approval authority, lost email approvals, duplicate records, inconsistent budget coding, missing receipts, limited audit visibility, and dependence on staff memory. — From the deck: Purchase requests break down across email and spreadsheets

Structured intake

One request begins one continuous record

A structured intake captures the required purchase details. Make generates a Request ID, creates one tracking record, identifies the appropriate approvers through a configurable approval matrix, creates a matching document folder, sets the initial status, and sends the manager a decision-ready request summary.

Slide showing the structured Google Form intake fields and the six actions Make performs: generate a Request ID, create the tracker record, look up approvers, create the document folder, set initial status, and send the manager review email. — From the deck: The request begins with complete, structured information

Approval routing

Approval authority determines the next step

Every request receives direct-manager review. The manager can approve it, return it for more information, or deny it. Returned requests are revised using the same Request ID rather than creating duplicate submissions. After manager approval, configurable rules determine whether the manager's authority is sufficient or whether secondary approval is required.

No purchase is approved automatically. The demonstration combines human approval decisions with policy-based routing driven by amount thresholds and budget category rules.

Slide showing manager review followed by policy-based routing: Route A stays within manager authority, Route B requires secondary approval based on amount thresholds and budget category rules. — From the deck: Approval authority determines the next step

Receipt collection and closeout

Approval is not the end of the process

After final approval, the requester receives a receipt-upload link. The receipt is connected to the original request, stored in the matching Google Drive folder, and used to update the existing tracking record. Missing receipts can trigger reminders, while completed requests close with their decisions and supporting documentation connected in one place.