Sample Request Form Template: Approval and Shipment Tracking

A sample request template should collect the requested product and variant, quantity, intended use, and delivery contact, then connect each approval and shipment to the same request ID. The files below give a product team a usable starting point for that workflow, including partial-shipment records.

Download the Excel workbook · Request items (CSV) · Reviews (CSV) · Example rows (CSV) · Shipment items (CSV) · Shipments (CSV) · Application field specification (JSON)

What to collect on the request form

Ask the applicant for their name, work email, organization, intended use, requested-by date, product or SKU, variant, and quantity. Collect a delivery address only when the request is ready for review, and restrict it to staff who handle fulfillment. Give every submission a stable request ID such as SR-1042; use that ID in review and shipment records instead of matching rows by a person's name.

A request can contain multiple products, so keep the submission header separate from its item rows. Store one row per requested SKU and variant in request_items. This lets a reviewer reduce or approve one line without rewriting the original request.

The quantities above are synthetic. The request totals 10 units; the reviewer approves 8. Preserve both values so the fulfillment team can see what changed.

Review the request without losing its original version

A reviewer records a decision, decision time, reviewer ID, and reason in a separate reviews log. If an applicant changes a request after review, create a new request version or reopen it with an auditable change record. Do not silently replace the approved quantity: the shipment limit must refer to the version the reviewer approved.

Use explicit states such as submitted, needs_information, approved, partially_shipped, shipped, and declined. Approval permits fulfillment of that version’s quantities. Count shipped quantities only after dispatch; a created shipping label remains pending.

Record one or more shipments against approved items

AI-generated editorial illustration.

Create one shipments row for each dispatch and one shipment_items row for each product in that dispatch. For SR-1042, a first shipment could send four MUG-12 units and one TEE-04; a second could send the remaining two mugs and one tee. Sum shipped quantity by request item and block any amount above its approved quantity.

Keep tracking number, carrier, dispatch date, delivery status, and fulfillment notes on the shipment record. Treat carrier tracking as manually entered unless a separately verified connector is configured.

Use the included template files

sample.csv contains synthetic request headers. The related files request_items.csv, reviews.csv, shipments.csv, and shipment_items.csv show how to keep products, review decisions, and partial dispatches linked. form-template.json describes the applicant form and internal review fields. These are original starter designs; adapt required fields, retention rules, and staff access to your operation.

Build a request tracker in Atoms

Choose Atoms Cloud or connect one Supabase project to the Atoms project; Atoms documents them as alternative backend choices. The connection must be used by the app’s save and readback flow, then checked after a refresh against the selected database. Supabase row-level security can express access policies; write and test policies for the actual roles and tables.

Keep applicant access limited to their own request and status. Only authorized fulfillment staff should see delivery addresses. Enforce these rules on the server and test with separate applicant and staff accounts. A hidden address field does not prevent an unauthorized database read.

Atoms backend connection guide · Supabase access policies

Build prompt

Copy the full prompt into your Atoms project chat and confirm the resulting tables, permissions, and save/readback behavior before using real applicant data.

Build a sample-request tracking app for a small product brand. Use either the project's Atoms Cloud backend or its connected Supabase project, never both at once. Create requests, request_items, reviews, shipments, and shipment_items with stable IDs and foreign keys. Add request_version to request items and reviews, and approved_review_id to dispatched shipments. A request has one or more product/variant lines, requested quantity, applicant, intended use, requested date, and private delivery details. Preserve the requested quantity and the approved quantity separately. Each review records reviewer, decision, timestamp, and reason. Each shipment has a request ID, dispatch date, carrier name, tracking number, status, and shipment item rows.

Roles: applicants can create requests and read only their own non-sensitive request status; reviewers can read request fields excluding delivery addresses and create review records; fulfillment staff can read approved item quantities and delivery details and create shipments; administrators can manage role access. Enforce organization, owner, and assigned-role access on the server and database. Do not expose delivery addresses to other applicants or include them in public exports.

Validate positive integer quantities, known SKU/variant values, valid email, and required fields. Permit partial shipments, but reject dispatched totals above the quantity in the linked approved review version. A label-created shipment is pending and must not reduce remaining-to-ship quantity. Approval must not mark a shipment as dispatched. Keep review and shipment history; do not overwrite or delete completed records when a request changes. Use a unique request ID and deduplicate imported rows by their source IDs.

Seed only the synthetic example: request SR-1042 asks for 8 MUG-12 Sand/12 oz units and 2 TEE-04 Navy/M units; approve 6 mugs and 2 tees; record two shipments of 4+2 mugs and 1+1 tees. Show the request, approval, remaining quantities, and shipment history. Save one edit, refresh the app, and verify the value remains in the app and the selected backend. Test applicant and staff access with separate accounts, including attempts by another applicant and by a reviewer to read delivery addresses; both must be denied. Report each completed check and each uncompleted check. Carrier tracking is manual. Inventory reservation and payments are outside this workflow.

For importing an existing request tracker, use the spreadsheet-to-web-app checklist.