An Airtable product sample request workflow can collect the products and quantities someone wants to evaluate, keep the reason for the request beside those items, and give staff a separate approval and dispatch queue. Use miniExtensions for the request experience and Airtable for the review records. Treat the request as a proposed sample allocation, not a paid order or a stock reservation.

This is useful for manufacturers, distributors, and small wholesale teams that handle samples through email today. The fictional example is a packaging supplier, Fieldline Packaging, sending a retailer three sample boxes and one sample sleeve. The goal is to know exactly what was requested, what the team agreed to send, and what actually left the office.

Separate a sample request from a catalog selection

A catalog picker answers “which product?” A sample workflow also needs “how many, for what evaluation, by when, and what did we send?” Keep that context on the request instead of adding requester details to reusable product records.

For a one-product request, the existing catalog item request tutorial provides a smaller starting point. The design here adds separate line items because each product can have a different quantity and a different approval result. Linking two products to a request with one Quantity field would leave staff guessing which quantity belongs to which item.

Start with a few non-sensitive fictional products and a practice recipient address you control. Decide whether samples need human approval, whether substitutions are allowed, and who confirms delivery details before you build the form. Those are operating policies; a required field cannot decide them for you.

Use a request table and a line-item table

These are proposed Airtable fields, not a prebuilt inventory or fulfillment system.

  • Products: Product Code as primary text, Product Name as text, Sample Available as a checkbox, Sample Description as long text, and Photo as an attachment. Staff own this catalog.
  • Sample Requests: Request Number as primary autonumber, Contact Name and Company as text, Email as email, Intended Use as long text, Needed By as a date, Delivery Details as long text, and Request Status as a single select.
  • Request Status choices: Draft, Ready for Review, Needs Information, Approved, Partially Approved, Declined, and Dispatched. These names describe your team’s process; setting them does not run it.
  • Sample Lines: Line Reference as primary autonumber, Sample Request as a link to Sample Requests, Product as a link to Products, Requested Quantity as a whole-number field, and Requester Notes as long text.
  • Staff fields on Sample Lines: Approved Quantity and Dispatched Quantity as whole numbers, Decision as a single select, and Decision Notes as long text.
  • Staff fields on Sample Requests: Reviewer as collaborator, Reviewed On and Dispatch Date as dates, and Dispatch Reference as text. Use the reciprocal Sample Lines link to see the items together.

Create catalog products BOX-101, a small folding box, and SLEEVE-202, a printed sleeve. The fictional request asks for three BOX-101 samples and one SLEEVE-202 sample to compare fit around a new product. The two line records must point to the same request but retain separate quantities.

Configure the form without giving requesters catalog ownership

Create a miniExtensions Form for Sample Requests. Include the contact information, intended use, requested date, delivery details, and linked Sample Lines. Keep approval and dispatch fields out of requester inputs. Tell users that staff will review availability and confirm what can be supplied.

In the Sample Lines field, use the Create & Expand Records controls to allow line creation and editing. The linked-record form guide explains this parent-and-child structure. Its important timing caveat is that saved child-form changes can reach Airtable before the parent form is submitted. Do not treat the existence of one line row as a completed request.

On the main Sample Lines field, set Record Finder Options → Record Finder Mode to Hide record finder button. Requesters create their own lines; they must not browse or attach existing lines from other requests. Keep the Product finder available only for the deliberately shareable catalog. The linked-record controls guide explains these separate controls.

The line’s child form needs Product, Requested Quantity, and Requester Notes. On the Product field, disable product creation and expansion if requesters only need to choose a title. This permits a new sample line while leaving catalog changes with staff. Review the creation control and expansion behavior documentation before configuring each level.

Set the Product field’s Advanced → Allow users to link option to Single Record, following the single-selection instructions. Each line then has one product and one meaningful quantity. The main request can still contain several lines.

In Product’s Filter Records settings, offer only products where Sample Available is checked. The filter documentation distinguishes finder choices from existing selections. Use the finder filter to guide new requests, then review older selections if availability changes. This filter does not reserve a unit or prove that a warehouse has stock.

Keep incomplete work out of the fulfillment queue

For the first version, have a coordinator check incoming records and manually set Ready for Review only after the parent request, contact details, and all intended lines are present. Leave incomplete records in Draft or Needs Information. Record what is missing instead of silently inventing a quantity or delivery address.

This manual gate also catches someone saving a line and leaving the form. Do not connect an email, shipping, or stock-adjustment automation directly to “new line created.” If you later automate the gate, test the exact submission signal and partial-save behavior before relying on it. A visible Submit button does not make a multi-table workflow transactional.

Ask a useful evaluation question, such as “What fit or material characteristic will you assess?” rather than collecting unnecessary personal details. That answer helps staff choose an appropriate sample and follow up intelligently. Keep the requested date as a preference until staff have confirmed timing.

Record partial approvals without rewriting the original request

Suppose Fieldline can send two boxes but no sleeves this week. Keep Requested Quantity at three and one. Enter Approved Quantity 2 for BOX-101 and 0 for SLEEVE-202, with a clear explanation on each line. Mark the overall request Partially Approved after a reviewer has checked the decision.

If a substitute sleeve is acceptable, confirm it through your normal customer communication process. Add a separate agreed replacement line or preserve the proposed substitute in staff notes until it is accepted. Do not quietly change the linked Product and erase what the requester originally asked for.

The dispatch owner then records what was packed. Approved Quantity and Dispatched Quantity may differ if a sample is damaged or unavailable during packing. Reconcile the difference, record the dispatch date and reference, and only then mark Dispatched. Neither an approval nor a printed label proves that the package has left.

Run a realistic acceptance check

  • Submit the fictional two-product request and verify both line relationships and quantities in Airtable.
  • Confirm that the requester can create Sample Lines but cannot browse or link another requester’s existing lines, create or edit Products, or enter approval decisions.
  • Try a blank, zero, and negative quantity in a practice request. Establish appropriate validation and ensure staff also review unusual quantities.
  • Save a child line without completing the parent. Confirm it cannot enter the packing queue accidentally.
  • Make one product unavailable, then check both a new request and an existing saved request. Document how staff resolve the older selection.
  • Record a partial approval and dispatch. Confirm the original requested quantities remain available for comparison.

This is a proposed configuration and test plan, not a claim that a sample shipment has been tested or sent. Check your workspace’s current sharing and plan requirements, follow the sharing instructions, and inspect the published end-user link before inviting requesters.

The result is a small, auditable operational sequence: request, review, allocation decision, packing, and dispatch confirmation. It suits teams that need structured sample handling without building a full commerce system. Use dedicated inventory, shipping, and payment tools when those functions are required; this workflow deliberately makes no automatic reservation, billing, or delivery promise.