A stock count tells you how many microphones remain. An equipment-loan record answers a different question: who has Microphone Kit 03, when is it due back, and was that particular kit returned? This tutorial designs a small, staff-operated lending desk in Airtable, with miniExtensions scanning the equipment label when a checkout request is entered.
The example uses individually identified assets, not interchangeable quantities. It complements the basic inventory-management guide: each loan has its own borrower, due date and return history. Scanning identifies an asset; staff still confirm the handoff and return. There is no automatic reservation, identity verification or simultaneous-checkout protection implied here.
Decide what one record represents
Imagine a fictional community workshop lending a projector, two microphone kits and a camera. The equipment manager assigns a distinct code to each physical item: EQ-001, EQ-002 and so on. A kit with several components receives one code only if staff always lend and inspect it as one unit.
Use two Airtable tables. Assets describes the physical equipment. Loans records each separate lending episode. Returning an item updates its existing loan; borrowing it again creates a new loan. This preserves earlier borrowers and dates instead of overwriting them on the asset.
You need permission to build these tables, a miniExtensions account connected to the base, an appropriate Form, printed test labels and the device staff intend to use. Validate camera access on that device before relying on scanning. Keep the first version staff-operated; a borrower-facing portal adds access and ownership decisions beyond this workflow.
Build the asset and loan tables
The following schema is a proposed design, not an automatically installed template. Create the fields before configuring the form. Keep codes as text so leading zeroes remain meaningful, and establish a rule that each physical asset has one distinct, stable code.
| Assets field | Airtable type | Purpose and example |
|---|---|---|
| Asset name | Single line text; primary field | Readable title, such as Microphone Kit 03. |
| Asset code | Single line text | Label payload, such as EQ-003; check uniqueness operationally. |
| Availability | Single select | Available, On loan, or Maintenance; maintained by staff. |
| Contents | Long text | What staff must count at handoff and return. |
| Loans | Linked records to Loans | Reciprocal history created by the loan-to-asset relationship. |
| Loans field | Airtable type | Purpose and example |
|---|---|---|
| Loan number | Autonumber; primary field | Stable reference for this lending episode. |
| Asset | Link to Assets; one asset per loan | The physical item selected by scanning. |
| Borrower name | Single line text | Person receiving the equipment. |
| Borrower email | Contact information; not proof of identity. | |
| Due back | Date with time | Agreed return deadline. |
| Submitted at | Created time | When this record was created, not necessarily handoff time. |
| Checked out at | Date with time | Actual handoff, entered by staff. |
| Returned at | Date with time | Actual return, entered after inspection. |
| Outcome | Single select | Requested, On loan, Returned, or Canceled. |
| Condition notes | Long text | Missing components, damage or other handoff details. |
Allow multiple historical Loans on an Asset, but configure each Loan’s Asset link for a single item. Lending two items means two loan records. Agree on the timezone staff use for date entry and review; otherwise a clear-looking deadline can still be misunderstood.
Configure scanning without replacing readable titles
Create a miniExtensions Form for new records in Loans. Include Asset, Borrower name, Borrower email and Due back. Keep operational outcome and handoff fields in the staff-managed Airtable process rather than asking borrowers to assert that equipment was issued.
In the Asset linked field, open Record Finder Options. Choose the list finder and enable its barcode/QR scanning option. Set its barcode search field to Asset code; otherwise scanning searches the record title. This lets the visible name remain “Microphone Kit 03” while the label contains “EQ-003”. The linked-record scanning documentation gives the current controls.
For a deliberate desk workflow, disable automatic camera startup and automatic linking after a successful scan. Staff can initiate scanning and inspect the match before choosing it. These options control the finder interaction; they do not submit the parent loan form or mark an asset as unavailable.
Under Create & Expand Records, disable creation of new Assets from this form. Consider disabling expansion/editing too: staff should select an existing item, not alter its catalog details during checkout. The linked-record child-form documentation explains that selection can remain available when expansion is disabled.
Use availability as guidance, not a lock
Optionally restrict the finder to Assets whose Availability is Available. In the field’s Filter Records section, enable filtering and add that condition. Use the finder-only application mode for this checkout selector. The filter documentation distinguishes finder filtering from also hiding selected records.
This improves selection, but the proposed Availability field is manually maintained. A staff member must still check existing open loans and the physical item before handing it over. Two people could begin with the same availability information. Do not advertise the form as a reservation system or assume that a filter provides an atomic lock.
Keep staff ownership explicit: one person confirms each handoff. If multiple desks must lend concurrently, define and test a separate concurrency process before rollout rather than treating this tutorial as sufficient protection.
Record a checkout and complete the handoff
For the first example, set Microphone Kit 03 to Available and place its EQ-003 label on the case. Staff open the form, scan the code, confirm the readable asset title, enter fictional borrower Alex Morgan and select the agreed deadline. Review the form and submit once.
In Airtable, locate the resulting Loan. Confirm that its Asset points to the intended record and that borrower and deadline are correct. If the record is only a request, leave the handoff timestamp blank and assign Requested. A submitted form is not evidence that the kit physically left the desk.
At the actual handoff, check the contents, verify that no other active loan exists for the item, enter Checked out at, change Outcome to On loan and set the Asset’s Availability to On loan. These are deliberate staff edits in this design, not actions the scanner performs. Do not hand out the kit if those checks reveal a conflict.
Return the existing loan, not a new checkout
When the kit comes back, read its asset code and locate that Asset in Airtable. Follow its linked Loans and identify the On loan record using the borrower, loan number and handoff date. Do not select an old returned loan just because it references the same equipment.
Inspect the contents and condition. On that exact Loan, enter Returned at, add relevant Condition notes and change Outcome to Returned. Set the Asset to Available only if it is ready to lend again; choose Maintenance when inspection finds a problem. Retain the loan and its original dates as history.
This return procedure is intentionally manual. Scanning an asset label identifies equipment, not which historical loan should be closed. If two active loans appear, resolve the discrepancy before editing either. A later return interface can be designed separately once the team has a reliable rule for selecting the exact active transaction.
Handle exceptions and run acceptance checks
If a scan finds nothing, compare the decoded label with Asset code and confirm that the record passes the finder filter. The missing-search-result guidance specifically identifies filtering as a possible cause. Do not create a second asset merely to make a scan succeed.
A label containing a web URL is not the same value as EQ-003. Inspect label generation, accidental whitespace, damaged printing and duplicate codes. If the camera is unavailable, use the desk’s documented manual lookup procedure and confirm the title and code together. Do not assume offline submissions are supported.
Before real lending, run these checks with fictional records; they are a recommended test plan, not tests reported as completed here:
- Scan a known Available asset and verify the correct link after submission.
- Scan an unknown code and confirm staff stop rather than choose an unrelated item.
- Attempt an On loan asset and inspect both filter behavior and the staff conflict check.
- Submit the same request twice and practice identifying the duplicate before handoff.
- Return one loan, then borrow the same asset again; verify both lending episodes remain distinct.
- Return damaged equipment and verify Maintenance prevents the next routine checkout.
The useful result is a clear chain from physical item to borrower, deadline and return—not merely a successful scan. Start with that auditable operational routine, then consider automation only after its triggers, duplicate handling and failure recovery have been designed and tested.
