Create Purchase Requests in SharePoint Without Code

You can run the entire purchase request process in SharePoint: a structured form with line items, approvals routed by amount, automatic notifications at every stage, a printable purchase order at the end, and views that show procurement exactly where every request stands. Ultimate Forms supplies each piece without code, and this guide builds the system step by step. Purchasing is the classic multi-stage approval, so this build is also the most common first application of the patterns in our complete guide to SharePoint approval workflows.

Why purchasing belongs in SharePoint

Purchase requests run on email and spreadsheets in more organizations than anyone admits, and the costs are predictable: requests lost in inboxes, approvals granted verbally and forgotten, nobody able to say what has been committed this month, and the surprise invoice that someone, apparently, approved. The process has everything a structured system wants to fix: clear data, clear rules, clear stages, and real money.

It also has a property that makes SharePoint the right home: purchasing touches everyone. Every department requests; one team approves and procures. A system in the platform people already use means no new logins, no per-requester licensing, and data that sits beside the budgets, vendors, and contracts it relates to.

Step 1: the list and the form

Create the list: in Site Contents, choose New, then List, and name it Purchase Requests:

With Ultimate Forms installed (the Installation Wizard takes minutes if it is not), open the list, click Design, and enter Form Designer. Create the columns from within the designer, New Column on the left, picking the right type for each:

• Request Title: single line of text
• Requested By: person or group (a value rule can default it to the current user)
• Department: choice or lookup
• Priority and Status: choice columns
• Payment Terms: choice
• Delivery Date: date
• Total Cost: currency

Keep the Attachments area on the form, since quotes and supporting documents arrive with most requests.

Step 2: line items, the upgrade most systems skip

A flat request, one description, one quantity, one cost, works until the first request for "3 laptops, 3 docking stations, and a monitor." Then the single Item Description column becomes a paragraph, and the Total Cost becomes arithmetic done in someone's head.

The real structure is a parent request with child lines, and an Associated Items column provides it: a Request Lines list (item, quantity, unit price, line total) displayed as a repeating table inside the request form, where users add lines without leaving the request. An Associated Items Summary column then computes Total Cost from the lines automatically, so the number the approval logic routes on is calculated, not typed. This one upgrade is the difference between a request form and a purchasing system.

Step 3: approvals routed by amount

Design the routing with the stakeholders before configuring anything; the rules are theirs, the wiring is yours.

The fast path is the Approval control: place it on the form, configure the stages, and use conditional approvers to express the thresholds, department head always, procurement above a limit, finance director above a higher one. Dynamic approvers resolve the department head from the Department lookup, so the routing table is data, not configuration. The control brings its own notifications, reminders, locking, and approval log.

The custom path builds the same behavior from Actions: Update list item actions conditioned on Total Cost and Priority set the Status and assign the approver, and Trigger Action buttons on the form give authorized approvers one-click Approve and Reject:

Either way, two actions close the loop: Approved sets the status and kicks off procurement steps; Rejected sets the status and returns the request to its requester with the reason.

Step 4: notifications that keep it moving

Alerts, under Design and Business Logic, carry the communication.

On submission, the assigned approver or finance team is notified, with Request Title, Requested By, and Total Cost as dynamic values in the message, the subject carrying the payload. On status change, the requester hears Approved or Rejected the moment it happens, with conditions keeping the audience to the requester and their manager. On silence, a reminder nudges the approver when a request sits pending past 48 hours, and the Approval control's escalation rules can copy a manager when reminders go unanswered. For approvers who live in Teams, the same alerts deliver to chats and channels with action buttons, so approval is one click from the message.

Step 5: visibility for procurement and management

Views do the daily work: group requests by Status, Pending, Approved, Rejected, showing Title, Requester, Department, Total Cost, and Priority. Color coding on the choice columns makes the grid scannable: green approved, yellow pending, red rejected, with priority highlighted the same way.

The weekly summary replaces the Monday status meeting's first twenty minutes: an alert in summary mode sends one organized email of active and recent requests, pending counts, and high-priority items:

Aging surveillance catches what individual reminders miss: an alert on requests pending more than five days notifies the requester's manager or finance, so nothing quietly fossilizes in the queue:

For the running totals management actually asks about, requests this month, spend by department, approval cycle time, counters and charts over the same list answer without a single export.

Step 6: the purchase order at the end

An approved request usually has one more obligation: becoming a document a vendor can receive. A Word print template with your PO letterhead renders the request, line items included, as a finished purchase order, and a Print list items action generates and emails it on approval, attaching a copy to the request for the record. The requester approves nothing extra and types nothing twice; the PO is a side effect of the approval.

Hardening the system for real money

Two refinements matter more in purchasing than in most processes, because the data is financial.

First, validation at entry: a validation rule requiring a quote attachment above a threshold, a delivery date that cannot precede today, and a rejection that demands a comment keep the record audit-ready from the first save. Second, lock what was decided: the Approval control locks the form during and after approval, so the amounts the approver saw are the amounts that stand, and where the stakes justify it, an electronic signature binds the approval to the exact values tamper-evidently. An auditor's question about any purchase, who requested, who approved, at what amount, against which quote, becomes a thirty-second lookup.

Build it or install it

Everything above assembles in an afternoon, and the first afternoon is even shorter with a template: the Purchase Order solution installs the full request-to-delivery process, and the Office Technology Purchase Request template covers the IT-specific variant, both free and adaptable in the browser.

Run the system in parallel with the old inbox for two weeks, then compare: every request visible, every approval recorded, every PO generated, and the month's committed spend one view away. Purchasing is where most organizations first discover what structured approvals can do, because the pain is universal and the payoff is countable in currency.