Equipment Inventory Template for Loans and Maintenance

An equipment inventory template for a shared workshop needs three linked records: the asset register, a dated checkout-and-return log, and a maintenance log. Stable equipment IDs let a team rename a tool or move it to another shelf without breaking its loan and repair history.

Download the Excel workbook · Loans (CSV) · Maintenance events (CSV) · Example rows (CSV) · Application field specification (JSON)

Start with one durable ID per asset

Assign each item an ID such as EQ-018 and keep it when the name, location, or condition changes. Record the serial number when the manufacturer provides one, plus the category, model, purchase date, home location, and active status. Do not use a row number or equipment name as the key; both can change.

The rows are synthetic. Derive the current borrower from the one open loan for an equipment ID. Store borrower and due date on the loan record, then close that record on return. This preserves who borrowed the item and when it came back.

Keep loans and returns as dated history

AI-generated editorial illustration.

Create one loan row at checkout with loan_id, equipment_id, borrower ID, checked-out time, due time, condition at checkout, and checkout staff ID. On return, update that loan with returned time, return condition, and receiving staff ID. Keep the completed loan row; a new checkout creates a new loan ID.

Enforce one open loan per equipment ID. In a multi-user app, make the check and insert atomic at the database so two staff members cannot check out the same tool at the same moment. At return, close the loan identified by loan_id; never infer which loan to close from the asset label alone.

Keep maintenance separate from borrower history

Log inspections and repairs in maintenance_events, with equipment ID, report date, issue, work performed, status, next inspection date, and technician. A reported or in_progress event places the equipment on hold; a completed event can release it after an authorized person records the result. Maintenance is its own history and should not erase or alter an earlier loan.

An asset is available only when it is active, has no open loan, and has no blocking maintenance event. A spreadsheet can display that rule, but formulas alone do not prevent simultaneous checkouts. For a web app, test the rule with two separate staff accounts and verify that the second checkout is rejected.

Use the included files

sample.csv lists assets. loans.csv includes an open loan and a completed loan; maintenance_events.csv shows an open repair hold and a completed inspection. form-template.json defines the proposed equipment, checkout, return, and maintenance fields. The example records are synthetic.

Build an equipment tracker in Atoms

Choose Atoms Cloud or a connected Supabase project for the app backend; Atoms documents these as alternatives. Build the data feature after connection, then confirm a test record survives refresh and appears in the selected database. Apply that save/readback check to an asset edit, loan checkout, return, and maintenance update.

Separate app users from workspace builders. Define staff roles such as borrower, checkout staff, maintenance technician, and administrator. Enforce who can read borrower details and who can check out, return, or release an asset on the server and database. If using Supabase, configure and test row-level security policies for the relevant tables.

Atoms backend connection guide · Supabase access policies

Build prompt

Copy the full prompt into your Atoms project chat. Load the synthetic rows first, then verify concurrent checkout, return history, maintenance holds, and persistence before recording live equipment.

Build an equipment inventory and loan tracker for a community workshop or small team. Use either Atoms Cloud or the connected Supabase project for this app. Create equipment, loans, maintenance_events, and people tables with stable IDs and foreign keys. Keep an immutable audit history for completed loans and maintenance events.

Equipment has equipment_id, serial_number, name, category, model, home_location, active status, and notes. Loans have loan_id, equipment_id, borrower_id, checked_out_at, due_at, returned_at, checkout_condition, return_condition, checkout_staff_id, and return_staff_id. Derive current_borrower from the single open loan; do not maintain a second editable current-borrower field. Maintenance events have event_id, equipment_id, reported_at, issue, work_performed, status, technician_id, completed_at, and next_inspection_at. Only active equipment with no open loan and no blocking maintenance event is available for checkout.

Roles: borrowers can view their own loans; checkout staff can create checkouts and close the selected loan on return; maintenance technicians can create and update maintenance events; administrators can manage people, roles, and equipment. Enforce organization, owner, and assigned-role permissions on the server and database. Protect borrower contact details from users who do not need them. Do not rely on hidden buttons for access control.

Use stable equipment and source IDs, deduplicate imports, validate timestamps and required fields, and reject a second open loan for the same equipment. Enforce the open-loan rule atomically so concurrent checkouts cannot both succeed. A return closes the matching loan without deleting its history. A reported or in-progress maintenance event blocks checkout until an authorized completion releases it. Renaming an asset or changing its location must not change its equipment ID or unlink its history.

Seed synthetic data: EQ-018 cordless drill has one open loan to P-014 due 2026-10-09; EQ-022 table saw has an in-progress maintenance event and cannot be checked out; EQ-031 clamp set is available; EQ-040 sander has a completed prior loan. Show current state and history for each. Test two simultaneous checkout attempts, return the correct loan, attempt checkout during open maintenance, and rename an asset while preserving its history.

Save an equipment edit and a loan update, refresh, and verify both in the app and selected backend. Test borrower, checkout staff, and maintenance roles with separate accounts; report every completed and uncompleted check. Do not assume a payment, shipping, or external maintenance integration.

For employee-issued laptops and exit receipts, use the IT asset inventory template.