A request form works better when people choose a known item instead of typing another version of its name. “USB-C adapter,” “USB adapter,” and “Laptop dongle” might all mean the same thing, but three new catalog records make later reporting harder.

This tutorial builds a small equipment-request form that links each request to one existing item. Requesters can search approved choices, but catalog maintenance stays with the team that owns the item list. The example uses fictional data and is a configuration walkthrough with acceptance checks to run in your own test setup.

Define the request and the catalog separately

Consider a fictional operations team that supplies meeting-room equipment. Staff should request a portable speaker or a USB-C adapter. They should not create a new catalog item just because they cannot find the right name.

Use two Airtable tables. Each Requests record represents one request for one item type. An Items record represents a reusable catalog entry. Several Requests records may link to the same Items record.

Items table

  • Item Code: primary single-line text field, such as ACC-101.
  • Item Name: single-line text, such as USB-C Presentation Adapter.
  • Picker Label: single-line text, such as ACC-101 · USB-C Presentation Adapter. Staff maintain this readable label in this example.
  • Catalog Status: single select with Active and Retired choices.
  • Internal Notes: long text for the operations team. Do not include it in the requester-facing form.

Requests table

  • Request Number: primary autonumber.
  • Requester Name: single-line text.
  • Requester Email: email.
  • Item: link to the Items table.
  • Quantity: number, configured for whole numbers.
  • Purpose: long text.
  • Review Status: single select with New, Reviewing, and Fulfilled choices, maintained by staff.

Seed three catalog records: ACC-101 USB-C Presentation Adapter, Active; AUD-201 Portable Speaker, Active; and ACC-099 VGA Adapter, Retired. Record the initial Items count of three. This makes the later test easy to interpret.

This is a proposed data model. It does not allocate stock, reserve equipment, or stop someone submitting two separate requests. If each request needs several items with separate quantities, use a line-item design instead of forcing several quantities into this single-item example.

Prepare a form for new requests

Connect the base to miniExtensions and create a Form for the Requests table. Include Requester Name, Requester Email, Item, Quantity, and Purpose. Keep the staff review fields out of this intake experience. Use a clear form title such as “Equipment Request.”

Before sharing with requesters, confirm that your workspace has a suitable paid plan or an active trial. The free plan documentation distinguishes builder testing from external sharing.

There are two different creation decisions here: creating a Requests record and creating an Items record. The main form needs to accept new requests. The linked Item field should only select an existing catalog entry. Changing one setting does not replace checking the other.

Click the Item field name and turn on Required in the top-left of its field settings. Do the same for Quantity and the requester contact fields. Keep these fields visible: the required-field guide explains that conditionally hidden fields do not enforce this rule. Leave Save & Continue off for this simple intake; test final submissions rather than treating partial saves as complete requests.

Turn off catalog creation in the Item field

Open the Item linked-record field’s settings in the Form builder. In Create & Expand Records, turn off Allow users to create new records. This is the documented control for the linked field’s Create New action. See how the Create New control is enabled or disabled.

For this simple picker, also turn off Allow users to expand (or edit) linked records. Leave the field editable and its record finder available so users can still select an item. The documentation explains that disabling expansion still permits linking records, while limiting the display to their titles.

A requester who cannot find an item should contact the catalog owner rather than create a guessed replacement. Add that instruction to the field description. Staff can then decide whether the item already exists under another name or genuinely needs a new catalog entry.

Set one item per request explicitly

In Form Fields, select Item, open Advanced, and set Allow users to link to Single Record. Configure this in miniExtensions even if the Airtable linked field is already set to allow one record. The single-record selection guide says the miniExtensions setting must be set separately.

Quantity now has a clear meaning: two units of the selected item, rather than an ambiguous quantity spread across multiple selections. The operations team still decides whether the quantity is available and appropriate during review.

Make the choices readable

The primary field is an item code, which is useful for staff but not enough for everyone choosing equipment. In the Item field’s View section, set Record title to Select another field, then set Custom field for record title to Picker Label.

The custom record-title documentation explains how to select the display field. If it is left blank, miniExtensions falls back to the linked table’s primary field and shows a publishing warning; the missing selection does not itself block publication. Use the readable text field, not an attachment or linked-record field.

Keep labels specific. “Adapter” is harder to distinguish than “ACC-101 · USB-C Presentation Adapter.” Before release, ask a colleague unfamiliar with your codes to choose the correct item from the sample list.

Offer active items in the record finder

In the Item field’s Filter Records section, enable Filter Records and add a static condition that Catalog Status is Active. Use Record Finder as the Filter application mode for this new-request example.

The linked-record filtering guide separates choices in the finder from records already selected. Its Record Finder + Selected records mode can also hide existing linked values that fail the conditions. Decide deliberately before applying that broader mode to an editing workflow.

Here, the expected result is that the two Active items are available for selection and the Retired VGA Adapter is absent. Retiring an item later should prompt a review of outstanding requests; this filter is not an automatic cancellation process.

Explain search before people report a missing item

A large catalog may not appear in full when the dropdown first opens. miniExtensions documents an initial load of the first 100 records and a search box for finding additional records. Add a brief instruction such as “Type the item name to search; contact Operations if you cannot find it.” See the record-finder search explanation.

When a choice seems missing, check its Catalog Status and readable label before adding a replacement. Do not treat absence from the initial dropdown as evidence that the catalog record does not exist.

Publish and check the requester experience

Publish the extension, then use Share → Copy URL in the Form builder to open its end-user link. According to the sharing guide, configuration changes stay in Draft until published. A successful builder preview alone does not establish what requesters will see. After any later adjustment, publish again and reload the shared form before repeating the checks.

Run the acceptance checks

Use fictional requests in a separate test setup before opening the workflow to staff:

  • Try submitting with Item or Quantity empty. Confirm the visible required fields block final submission.
  • Search for USB-C Presentation Adapter and select its existing record. Confirm that Create New is unavailable and the catalog record cannot be expanded for editing.
  • Try selecting a second item. Confirm that the form follows the single-record setting.
  • Search for the Retired VGA Adapter. Confirm that it is excluded from new choices.
  • Submit a request for two adapters. In Airtable, confirm one new Requests record, the correct linked ACC-101 item, and Quantity 2.
  • Check that Items still contains three records and its original names and statuses are unchanged.
  • Repeat with a second fictional requester selecting ACC-101. Confirm two separate requests link to the same catalog record.

These checks are a test plan, not a claim that this example has been run. Also test any later changes that enable expansion, creation, editing, or different filter modes.

Keep catalog ownership clear

This form reduces one common source of duplicate catalog entries: requesters creating them during selection. It does not merge existing duplicates or control every other Airtable entry point. Assign someone to review proposed items, consistent codes, retired entries, and confusing labels.

If you instead need logged-in users to browse a gallery and maintain a personal selection list, start with the Product Catalog Portal tutorial. The form here serves a smaller goal: capture a new request that points to a catalog item your team already maintains.