An Airtable replacement parts request workflow can narrow part choices by equipment model, collect the reported problem and give staff a compatibility-review queue. miniExtensions provides the form and linked-record selection. Your parts team still checks the exact equipment, revision and requested quantity before confirming what should be supplied.

Consider fictional Northline Workshop supporting two desk-lamp models. Both use a joint cover, but the replacement cover for Model A does not fit Model B. A generic dropdown containing every part invites mistakes. The useful outcome is a request linked to a known model and candidate part, with the original symptoms retained for review.

Model compatibility as data your team maintains

Use these proposed Airtable tables and field types:

  • Models: Model code as primary single-line text, Model name as text and Identification instructions as long text.
  • Parts: Part code as text, Part name as text, Compatible models as a linked-record field to Models, Catalog state as a single select and Staff compatibility notes as long text.
  • Requests: Request reference as text, Requester name as text, Requester email as email, Reported model as text, Model and Requested part as linked records, Equipment revision as text, Requested quantity as a number, Symptoms as long text and Photos as an attachment.
  • Requests, staff fields: Review state as a single select, Confirmed part as a linked record to Parts, Confirmed quantity as a number, Customer summary as long text, Reviewer as text, Reviewed on as a date and Fulfillment reference as text.

Add models NL-A and NL-B. Create parts JC-A and JC-B, linking each to its supported model. A shared base pad can link to both models. This is a catalog relationship entered and verified by staff; the presence of a link does not prove compatibility was assessed correctly.

Keep Reported model separate from the Model link. A customer may type “older Northline lamp” while staff identifies it as NL-A after reviewing a photo. Retaining the customer’s wording helps explain the correction. Avoid collecting unnecessary identity documents or payment information to establish which model they own.

Filter the candidate parts before selection

Create a miniExtensions Form for Requests. Configure Requested part to select existing Parts records. In the linked field’s Filter section, enable Dynamic filtering and use the Compatible models relationship as a filter field. The dependent dropdown documentation explains the supported linked-record relationships and filter behavior.

Let the requester select a model before choosing a part. In the filter field settings, review whether adding linked records is allowed while the filter is empty. For this workflow, do not offer an unrestricted parts list as the default path. Test the actual choices with NL-A, NL-B and a blank selection rather than assuming the visible model label has filtered anything.

The filter selection is a picker aid. Keep the explicit Model field in Requests and reconcile it with the customer’s reported model and requested part during review; do not assume a filter value automatically populates that separate field. If you choose another data-entry arrangement, verify precisely which values reach Airtable.

Disable part creation and part editing in the linked field’s Create & Expand Records settings. The creation and editing guide describes these controls. Customers should request an existing part, not add a new catalog entry when they cannot find one. The existing catalog item tutorial covers the underlying selector pattern.

Keep an unknown-part route available

Some customers know the symptom but not the part name. Let them leave Requested part empty and describe what happened in Symptoms. Ask for a relevant photo and Equipment revision where available. A message such as “The cover beside the adjustment knob cracked” is more useful than forcing an inaccurate choice just to submit the form.

Use plain instructions to show where a model label might be found, based on your own equipment documentation. Do not tell people to dismantle equipment or perform unsafe tests. For a fault involving safety or specialist servicing, route them to the appropriate support process rather than treating the form as repair advice.

Set a sensible Maximum allowed files for Photos using the attachment limit guide. Existing images count toward that limit. A limited upload field reduces clutter; staff still checks whether the images show the relevant label or component clearly enough.

Confirm the part without rewriting the request

Use Review state choices such as New, Identification needed, Compatibility review, Recommendation communicated and Fulfillment arranged. These are proposed custom values. Staff records Confirmed part and Confirmed quantity only after checking the model, revision and actual request.

For example, a customer selects JC-A but the photo shows Model B. Leave Requested part as JC-A and record JC-B as Confirmed part once verified. Customer summary explains the difference. The separate fields preserve what was asked and what staff recommended without making the customer appear to have requested the corrected part originally.

Keep staff fields out of the requester form. After review, disable customer editing of the reviewed record through the relevant form route or use a separately controlled follow-up process. A correction should not silently replace the evidence used for a completed compatibility decision. This design uses staff review and ordinary records, not an immutable audit system.

Separate recommendation from supply

A confirmed part may still be out of stock or require a quotation. Record the next action in Customer summary and use Fulfillment reference only when a separate order or dispatch process has actually been arranged. Neither selecting a part nor submitting this form reserves stock, takes payment or orders a shipment.

If the catalog later changes, review pending requests affected by the change. Do not automatically replace Confirmed part on earlier completed requests. Their recorded recommendation explains what staff decided at that time; a replacement recommendation deserves a dated review and clear communication.

Before launch, test both models, a shared part, an unknown part and a model change after selection. Inspect the saved Model and Requested part, and check that customers cannot create or edit catalog records. Test mismatched photos and unavailable parts in the staff queue. These are acceptance checks to run with fictional data, not claims of completed product testing.