An Airtable wholesale line sheet can present an approved range of products, variants and order quantities through a miniExtensions Interface. Pair it with a request form so a retailer can identify the exact SKU and quantity they want, then let staff confirm current pricing, availability and terms before accepting an order.

This works well for a small brand whose catalog changes more often than its exported PDFs. The example is fictional Harbor Paper Goods, selling notebooks in several sizes and colors. The aim is a maintainable buyer-facing range and a clear sales handoff, not instant checkout or a binding offer created by viewing a price.

Distinguish the product story from the orderable variant

A buyer may browse the Harbor Notebook collection, but staff fulfills a specific SKU: A5, dotted, navy. If the line sheet lists only the collection name, the sales team still has to ask which version and how many. Give every orderable combination a stable variant record.

Decide what the displayed price means before publishing. Label a sample trade price with its currency and applicable context, and explain that staff confirms the current offer. Keep negotiated account-specific pricing out of a public catalog. A public page is appropriate only for information the brand intends all visitors to see.

Model the approved range and incoming requests

  • Products: Product name as primary text; Collection as single select; Description as long text; Approved image as attachment; Published as checkbox.
  • Variants: SKU as primary text; Product as a link; Size and Color as single selects; Pack quantity as integer number; Display price as currency; Currency label as text; Public availability note as long text; Published as checkbox.
  • Buyer requests: Request reference as primary text; Buyer name and Business name as text; Work email as email; Delivery region as text; Requested timing as text; Request state as single select; Staff response as long text.
  • Request lines: Line reference as primary text; Buyer request, Requested variant and Offered variant as links; Requested packs as an integer number; Staff-confirmed packs as number; Confirmed unit price as currency; Staff line note as long text.

Use separate internal fields or tables for costs, margin and supplier information. Do not put them into the public preview or expanding form. Keep the buyer’s requested packs separate from the quantity staff can actually supply.

For a minimal one-SKU request form, put Requested variant and Offered variant as links, plus Requested packs and Staff-confirmed packs as number fields, directly on Buyer requests and omit Request lines. Introduce the line table when a properly configured multi-item form is needed, rather than leaving quantity without a clear home in the schema.

Publish only the intended catalog records

Create approved Airtable views filtered to Published being checked. Review products and variants separately: publishing a product should not accidentally reveal an unfinished variant. Configure the miniExtensions catalog to use those views and test the inquiry picker against the same intended range.

A no-login Interface fits a line sheet intended for all visitors. For individual buyer records or private commercial details, use an appropriately configured authenticated flow instead. Do not place request history in the public catalog.

Use collection views to make the range easy to browse. Under the table’s Views settings, Filter and Sort can use an Airtable view or custom settings, as the predefined-filter guide explains. For each displayed variant, show the SKU, size, color, pack quantity and clearly labeled price context.

Review preview fields and the expanded record separately using the field-display guide. A short card can hide useful specifications, while an overly broad expansion can expose internal details. Check both on a phone as well as a wider screen.

Collect the buyer’s request in unambiguous units

Suppose a retailer wants six packs of navy A5 dotted notebooks, with twelve notebooks per pack. Label the input Requested packs, not Quantity, and show the pack size beside the variant. Staff can interpret the request as 72 notebooks without guessing whether the buyer meant six individual units.

Use an existing-variant picker for Requested variant and prevent buyers from creating or editing SKU records through it. Ask for delivery region and desired timing, then let staff discuss shipping and timing through the normal sales process. Avoid requesting payment-card details or unnecessary personal information in the form.

A computed subtotal may be useful as an estimate, but it must not imply taxes, freight, discounts or stock have been confirmed. The simplest first version records the requested quantities and leaves the commercial calculation to staff.

Keep sales confirmation separate from catalog browsing

The sales team reviews the request, checks available stock and current terms, and records confirmed quantities and prices. If only four packs are available, leave the requested six intact and explain the partial offer. The buyer can then decide whether the alternative works.

Record an accepted order through the team’s established order process. This article does not configure payment, inventory reservation or fulfillment. A request state such as Offer sent should be used only after the actual communication, not because staff entered a number in Airtable.

If the team needs a PDF line sheet or order summary, treat it as a separately generated, reviewed output. Include its date and range context, and check prices and links before sharing. This design does not assume that an Interface automatically becomes a printable sales document.

Handle a discontinued variant without changing past requests

When a color leaves the range, remove it from new browsing and picker choices by changing its publication state. Keep its SKU record linked to past requests. Reusing the same SKU record for a different color would make historical requests misleading.

For a substitute, set Offered variant to the actual replacement variant in the staff offer and explain the difference. Do not overwrite the buyer’s requested variant. The useful history is what was requested, what was offered and what was eventually accepted, even if the public catalog now shows a different range.

Verify the buyer-to-sales handoff

Test an approved SKU, an unpublished SKU, a zero or invalid quantity, a partial offer and a discontinued variant. Confirm that public visitors cannot inspect prior buyer requests or internal pricing fields, including through expanded records. Reload Airtable to verify the request links and quantities.

Publish reviewed configuration before sharing the end-user link, following the sharing documentation. These are recommended checks, not observed tests. The result is a clearer wholesale conversation: buyers identify the products they want, and staff confirms a real offer using current operational information.