A return merchandise request portal in Airtable can connect a customer’s requested return to the original order, capture item-level reasons and show what staff have actually authorized. miniExtensions provides the customer-facing form and status views; your team controls authorization, receipt, inspection and any financial follow-through.

For fictional Harbor Goods, a customer ordered two lamps and one shelf. One lamp arrived damaged, while the shelf is simply the wrong size for the room. Those items may need different handling. A single return-reason field on the order would conceal the distinction, and a successful submission should not imply that either item has been approved for return.

Model the request at the item level

Prepare a connected Airtable base with these proposed tables. Use fictional orders before collecting real customer information.

  • Customers: Name as text and Email as an email field, with one record per portal user.
  • Orders: Order reference as text, Customer as a linked record, and Order date as a date.
  • Order lines: Line reference and Product description as text, Order as a linked record, and Ordered quantity as a number.
  • Return requests: Request reference as text, Customer and Order as linked records, Submitted context as long text, and Customer status as a single select.
  • Return items: Item reference as text, Return request, Customer and Order line as linked records, Requested quantity as a number, Reason as a single select, Details as long text, Photos as an attachment, Authorization decision as a single select, Authorized quantity as a number, and Return instructions as long text.
  • Receipt checks: Check reference as text, Return item as a linked record, Received quantity as a number, Received date as a date, Inspection notes as long text, and Inspection outcome as a single select.

Keep customer-reported information on Return items and staff-owned fields such as Authorization decision, Authorized quantity and Return instructions separate. Each receipt check records a physical inspection event. This supports split parcels without replacing the first receipt when another arrives.

For order HG-204, create separate return items for one lamp and one shelf. Leave the second lamp out of the request. Staff can then authorize the damaged lamp while asking for more information about the shelf without presenting an all-or-nothing order status.

Choose an intake path that keeps order context clear

For repeat customers, configure a portal with Return requests as its Data Table and Customer as the linked User Field. Any other table shown directly, including Return items, needs its own direct user relationship. Follow the Users table setup guide rather than assuming that a relationship through Orders provides the portal user link.

Use a suitable verified login method from the login guide, then restrict every private view to the user’s linked records. The personal-record view instructions identify the exact setting. Test the order selector and expanded record forms too: limiting the request list alone does not demonstrate that all linked-order choices are appropriate.

A conservative first version has staff identify the order and create the requested item records after reading an intake form. Customers then supply reasons and photos on those records. This avoids exposing a catalog of other customers’ orders. If you later let customers choose order lines, configure and verify the picker scope before launch.

miniExtensions also supports creating or editing linked records through a form. If you use that route for multiple return items, read the linked-record form guide carefully: saving a child form can update Airtable before the parent form is submitted. Treat partial requests as possible and give staff a way to distinguish incomplete intake from a request ready for review.

Ask for useful evidence without promising an outcome

Use concrete reason choices such as Arrived damaged, Incorrect item and Other, with a text field for the customer’s explanation. These are routing aids, not policy decisions. Ask for a photo of the affected area when relevant, without requesting payment-card images or unrelated personal documents.

Configure Maximum allowed files on the photo attachment field if you need a modest limit. The attachment-limit documentation explains that existing files count too. A photo field with two existing images and a limit of three has space for one additional image. Staff still decide whether the evidence answers the question.

Keep the customer’s requested quantity distinct from the staff-authorized quantity. A request for three units against an order line of two should enter an exception review, not silently become an accepted return. Staff compares the original order and any previous returns before authorizing; this design does not implement a transaction-safe quantity reservation.

Track authorization, arrival and inspection separately

Use custom customer statuses such as Received for review, Information needed, Instructions available and Review complete. Avoid “Approved” unless the actual policy decision has been made and its scope is clear. The team should write explicit instructions identifying which item and quantity are authorized and where the customer should find the agreed return process.

When a parcel arrives, create a Receipt checks record for the item actually received. For the damaged lamp, the receiver records one unit and the observed condition. If the customer also included the shelf without authorization, keep that as an exception for staff review. Do not rewrite the original authorization to make it appear that both were approved earlier.

After inspection, staff records the next operational step and communicates it through the business’s normal process. A refund, replacement shipment or credit remains a separate action in the appropriate system. A status field in Airtable does not issue money, buy a shipping label or prove that the customer has been contacted.

Check partial and duplicate cases before launch

Run one fictional order through a complete return, a partial return and a second request for the same line. Confirm that staff can see earlier quantities and recognize a potential duplicate. Keep canceled and declined requests available to authorized reviewers rather than using them as evidence of a physical receipt.

Test with two customers, confirm that each sees only the intended requests and items, and check that neither can edit authorization or inspection fields. Open the published experience on mobile and verify that photo uploads land on the correct Return item. These are acceptance checks to perform, not tests claimed as completed here.

For a related but different process, the warranty claim guide focuses on coverage review. An RMA workflow focuses on whether specific merchandise may be returned and what arrived afterward. Start with clear item-level records and manual decisions; add shipping, reminders or financial integrations only as separately designed and tested requirements.