A list of linked records can contain everything a reviewer needs and still be easy to skim past. A workshop coordinator might see three preparation items, press Submit, and only later discover that one contained an important instruction. A useful review form makes the individual items part of the interaction rather than leaving them as background information.
This tutorial builds a fictional workshop review pack with Airtable and miniExtensions. Staff prepare the pack in advance. The reviewer opens each assigned item, then records a decision and any questions on the parent form. The design is deliberately narrow: it guides a review, not a complete approval system or a certified audit trail.
Define the review pack
Imagine a small ceramics studio preparing its Saturday workshop. The coordinator wants a colleague to inspect the room layout, material quantities and arrival instructions before confirming readiness. Those three items are prepared by the coordinator, not chosen by the reviewer.
Keep two responsibilities separate. Staff decide what belongs in the pack and maintain the instructions. The reviewer reads that assigned material and returns a response. For the first version, create records and assign links manually in Airtable. No automation is needed to demonstrate the pattern, and none is implied by the schema below.
You need an editable Airtable base connected to miniExtensions, permission to configure a Form, and a few fictional records for testing. Start in practice tables rather than with operational or sensitive information. Decide how the reviewer will access the correct parent record before distributing the form.
Build two connected tables
Create a Review Packs table with the following fields. Field names and choice values are suggestions for this example, not built-in miniExtensions settings.
| Field | Airtable type | Purpose |
|---|---|---|
| Pack | Single line text; primary | Saturday pottery workshop — preparation review |
| Workshop Date | Date, without time | Identifies the workshop being checked. |
| Review Items | Link to another record: Pack Items; allow multiple | The fixed set of items staff assign. |
| Decision | Single select | Ready; Questions to resolve; Not ready |
| Reviewer Notes | Long text | The reviewer’s explanation or questions. |
Create Pack Items as the linked table. Give it Item as a single-line-text primary field, Instructions as long text, Reference URL as a URL field, and Sequence as an integer Number field. Airtable’s reciprocal link identifies the associated review pack; name it Review Pack. For this design, assign each item to one pack rather than reuse the same item across unrelated workshops.
Create three items: “Room layout”, “Clay and tools”, and “Arrival instructions”. Write actual review prompts: check whether the layout leaves room for twelve participants; confirm the planned material quantities; compare the arrival instructions with the advertised start time. Use fictional reference links or leave Reference URL blank until you have an appropriate document.
Link all three items to the Saturday pack before opening its form. Sequence is useful for staff organisation, but a Number field alone does not configure the display order in miniExtensions. Give item names enough context to remain understandable whichever order appears.
Open the existing pack, not a new blank submission
Create a miniExtensions Form connected to Review Packs, with editing enabled. Include the pack name, date, assigned items, Decision and Reviewer Notes. The parent record already contains its three links, so the reviewer should open that record rather than start by selecting items in a blank form.
For a direct-link example, use the builder’s Share menu, enable Allow users to update existing records, then choose Get Edit URL. Copy the generated formula into an Airtable formula or button field and use the Saturday pack’s resulting URL. Copy your own generated formula rather than constructing an extension identifier by hand. The editing-records guide explains this route and notes that the formula option is unavailable with login enabled.
Use this direct-link exercise with non-sensitive test information. A link is not a substitute for deciding who should have access. For an operational workflow, choose and verify the appropriate access arrangement separately; don’t remove an existing login just to follow this example.
Require opening the assigned items
In Form Fields, select Review Items. In the creation/expansion section—named Create & Expand Records in the current creation-controls guide and Creating and Editing Records in the review guide—enable Allow users to expand (or edit) linked records and Require users to open linked records. The linked-record review documentation describes an unread indicator that clears when a record’s child form is opened. The requirement checks the linked records currently displayed, rather than only the set present when the form was first opened.
Keeping the pack preassigned makes responsibility clear: staff define what must be reviewed, while the reviewer responds to that scope. If you allow membership changes, test the opening requirement against the final displayed set before submission. In this walkthrough, changing the assigned three-item scope remains a coordinator decision.
Keep item contents and membership under staff control
Open the editing child form through the linked field’s Form Settings. Show Item, Instructions and Reference URL, and make each displayed field read-only. Check the child configuration rather than assuming the parent field controls all editing. The expand-without-editing guide explains that when all child fields are read-only, the child submit button is hidden. The parent can still collect the separate decision and notes.
For checklist membership, open Record Finder Options and enable Hide record finder button; leave Allow users to unlink existing records disabled. The unlinking guide documents these controls. In the linked field’s Create & Expand Records controls, turn off record creation so reviewers cannot add checklist entries. The creation-controls guide explains that child creation is controlled at the parent linked field, not through the standalone form’s Share settings; disabling creation covers both the main create control and creation in the finder. Confirm the actual end-user screen offers neither removal nor creation in your setup.
Set the parent pack name and workshop date read-only as well. Leave Decision and Reviewer Notes editable. This is a form interaction design, not a claim that it prevents changes through every other Airtable integration or collaborator account.
Ask for a useful response, not an automatic approval
Opening an item shows that the interface was opened; it does not demonstrate that someone understood the instruction, checked a physical room, or approved its contents. For that reason, keep Decision explicit. A reviewer who finds the clay quantity too low can choose Questions to resolve and write “Please confirm the amount for twelve participants” instead of treating every opened item as a pass.
In this example, the coordinator reads the returned decision in Airtable and resolves questions manually. No email, escalation, status transition, signature or per-item completion timestamp happens merely because those fields exist. If you need item-by-item answers or independent reviewer histories, design separate response records and evaluate that workflow on its own merits.
Run an acceptance check before sharing
The following is a recommended test plan, not a claim that this example has been run against your base.
- Open a test pack containing three preassigned items. Confirm its title, date and complete item set match Airtable.
- Attempt submission without opening the items, then after opening only two. Confirm the requirement prevents an incomplete pass.
- Open the remaining item, enter a decision and notes, and submit. Read the exact parent record in Airtable to verify the saved response.
- Try changing an instruction, removing an assigned item or creating another. Confirm the intended view-only content and fixed membership.
- Check a fresh pack and a reopened pack separately. Record observed behaviour rather than assuming the opening state is a permanent, cross-session audit record.
- Test an empty pack. Staff should catch missing assignments before sending it; an empty checklist is not evidence that required preparation exists.
- If using login or multiple reviewers, test with two distinct users and verify each person’s actual access separately.
If submission does not behave as expected, first check that you opened an existing parent with links already saved, that expansion and the opening requirement are enabled on the correct field, and that the published form reflects your current configuration. Once those checks pass, the result is a focused review experience: a deliberate set of supporting items, followed by a clear human response.
