An Airtable purchase requisition form can collect what an employee wants to buy, why it is needed, and the details a manager should review before ordering. Use separate request revisions and item rows so a changed quantity does not silently inherit an earlier approval. miniExtensions provides the requester-facing form or portal; staff retain responsibility for the decision and the actual purchase.

This workflow suits a small operations team that already tracks requests in Airtable. It produces a reviewed request package for a buyer, including the specific revision and lines considered. It does not reserve budget, create a binding purchase order, or move money.

Before inviting end users, confirm a suitable paid plan or active trial for sharing, and check the workspace-wide child-form allowance for this setup.

Define the decision the manager is making

Imagine a fictional design company, Willow Works. Studio coordinator Dana requests two display monitors and two monitor arms for a new work area. Manager Lee checks the business need and estimated cost. Buyer Sam checks the final supplier offer and places any authorized order through the company’s purchasing process.

Agree on a plain-language decision: Lee is approving the described items and estimated amount for procurement to consider under company policy. The buyer still needs to check the final price, availability, delivery details, and purchasing authority. An estimate below a threshold does not establish that funds have been reserved.

Use one currency for the initial workflow. Give quantities explicit units, such as Each, and distinguish estimated product costs from shipping and other expected charges. Asking for a business reason and required date helps the manager evaluate the request rather than simply count completed fields.

Use a stable request with separate revisions and lines

Create the following suggested tables and fields in a practice base. All statuses are proposed workflow labels that your team maintains.

  • Requesters: Name as primary single-line text, Email as an email field, and Department as a single select. One person is one portal user.
  • Purchase Requests: Request Reference as primary text, Requester as a single link, Business Purpose as long text, Required By as a date, and Current Revision as a single link to Request Revisions.
  • Request Revisions: Revision Reference as primary text, Purchase Request as a single link, Requester as a direct link to Requesters, Revision Number as a number, Justification and Change Summary as long text, Currency as a single select, and Requester Ready as a checkbox.
  • Revision review fields: Review Stage as a single select: Draft, Submitted, Changes Requested, Approved, Declined, Superseded; Manager as a collaborator; Decision Notes as long text; and Decision Date as a date.
  • Requested Items: Item Reference as primary text, Request Revision as a single link, Description and Specification as long text, Quantity as a number, Unit as text, Estimated Unit Cost as currency, Supplier Reference as a URL, and Line Estimate as a formula multiplying Quantity by Estimated Unit Cost.
  • Revision estimates: Item Estimate as a rollup of linked Line Estimate values using SUM(values), Estimated Shipping and Estimated Other Charges as currency fields, and Estimated Total as a formula adding the three amounts.
  • Buyer Handoffs: Handoff Reference as primary text, Approved Revision as a single link, Buyer as a collaborator, Procurement State as a single select: Not Ordered, Checking Details, Ordered, Cancelled; Order Reference as text; and Ordered On as a date.

Create request WW-104 and revision WW-104-R1. Add two monitors at an invented estimated unit cost of $220 and two arms at $45. The item estimate is $530. With $30 estimated shipping and zero other charges entered explicitly, the estimated total is $560. Check that both line rows link to R1 rather than directly to the request.

Staff prepare the request header and revision in this first version. This keeps identity, manager assignment, and revision numbering under staff control. Requested items belong to one revision; copying a request later means creating new item rows, not linking a new revision to the old editable lines.

Let the requester complete the prepared revision

Create a miniExtensions Portal using Request Revisions as the data table and Requester as the user relationship. Let Dana complete Justification, Change Summary, and Requester Ready, plus the requested-item details in linked child forms. Keep review decisions, manager assignment, and the stable request links outside the requester’s editable fields.

For the linked Requested Items field, follow the linked-record permission settings. Leave the parent field’s Read only setting off, hide the record finder, and disable unlinking. Keep expansion available. Staff create the initial item rows, so also disable creation in this version. Configure the child form’s editable inputs separately: description, specification, quantity, unit, estimated cost, and supplier reference.

Do not expose an unrestricted catalog or another request’s items through an expandable relationship. If an additional item is needed, the coordinator adds it to the correct draft revision. This deliberate first version trades self-service row creation for a smaller set of relationships to check.

Use email verification in Users & Login → Login Fields, with one valid email per requester. Set every private portal view to Personal records only (linked to the logged in user). The manager and buyer work in Airtable rather than this requester portal.

Review a submitted package, not a partially saved item

Dana fills both item rows and checks Requester Ready. The coordinator checks completeness and marks Review Stage Submitted. Lee then reviews the exact revision, its item specifications, quantities, units, estimate, and business justification. Ask for missing taxes or shipping assumptions to be clarified rather than assuming that a blank charge means zero.

The multi-table form guide explains that child-form saves can reach Airtable before the parent is submitted. A saved monitor row therefore should not trigger approval or ordering. Use the completed package and human review as the decision boundary.

For submitted revisions, configure client-editable values to show as read-only using the documented conditional-field workaround. Review Stage stays staff-controlled. Keep inline editing disabled. Give item rows a lookup of that stage and configure their fields too; restricting only the revision header leaves the item details editable. The actual Read-only setting itself is not conditional.

After checking the package, Lee records Approved, the decision date, and notes identifying what was reviewed. Sam creates a Buyer Handoff linked specifically to WW-104-R1 and starts at Not Ordered. These are manual steps, with no payment connection or supplier message triggered by the status change.

Send a changed quantity through a new review

Before Sam orders, Dana learns that the work area needs three monitors and three arms. The coordinator creates WW-104-R2 and copies the request details into new item rows. Dana explains the increase in Change Summary. R1 retains its original two-monitor request and decision.

Sam pauses purchasing while Lee reviews R2. At the same illustrative unit costs, three monitors and three arms produce $795 in items; with $30 shipping, the new estimate is $825. The earlier $560 decision should not be interpreted as approval of this change.

Mark R1 Superseded only after the team has decided which revision is current, retaining its decision notes. Update the buyer handoff deliberately after the new decision. If an order was already placed, handle the proposed change through the supplier’s order-change process; a new Airtable revision cannot change that existing commitment.

Close the loop with evidence of the actual order

When Sam has checked the current approved revision and completed the purchase through the authorized channel, they enter the real Order Reference and Ordered On date. Only then should Procurement State become Ordered. If stock is unavailable, keep Checking Details and record the next action rather than marking the requisition fulfilled.

Keep validation modest and specific. You can require a positive quantity using Field Validation. Keep inline editing disabled so quantity entry follows the validated child form. Test a blank, zero, negative, and positive quantity. A positive number still does not prove the correct unit, a fair price, or budget eligibility. Those are reviewer questions.

Before use, test two requesters with separate requests. Confirm neither can select or open the other’s rows. Save one line without declaring the revision ready, try editing a submitted line, and create the three-monitor revision. Compare the retained R1 values and verify the buyer sees the intended approved version. Treat separate records as useful history, not an immutable audit log or a financial control certification.

For supplier price collection before the request is finalized, see the supplier RFQ workflow. Here the narrower outcome is internal purchase review: a preserved request, a specific manager decision, and a separate record of what the buyer actually ordered.