Airtable can organize rental move-in and move-out inspections when each visit has its own observations and photographs. With a miniExtensions Portal, an inspector can work through the assigned records while the property manager compares the two visits without replacing the original condition report.
Consider fictional Alder Lane Rentals. Unit 4B has a marked kitchen counter when a tenancy begins. At move-out, the inspector sees the same mark and a loose cabinet handle. The manager needs to distinguish an existing observation from a later finding, see the supporting images and identify anything that still needs clarification.
The useful outcome is a paired condition record. Questions about responsibility, normal wear, legal notice or deposit deductions require a separate process and appropriate advice.
Before sharing externally, use an appropriate paid plan or active trial; the Free plan is for internal testing. Check your workspace-wide child-form allowance across all published extensions, including the tables and forms used here.
Give each tenancy its own comparison
A unit can have many tenants over time. Linking every photograph only to “Unit 4B” makes it easy to compare the wrong visits. Start with a tenancy record, then place its move-in and move-out visits beneath it. Preserve the tenancy link even after a new resident occupies the unit.
The broader property management guide covers units, leases and tenant services. This workflow adds item-by-item evidence pairing. The field inspection guide provides a related observation-and-follow-up pattern, but a rental comparison also needs a stable baseline and an explicit answer when no baseline exists.
For this example, Morgan inspects the unit and Priya reviews the reports in Airtable. Residents do not edit either inspector’s observations. If residents provide comments, staff retain them as additional evidence rather than rewriting what Morgan recorded.
Build records that preserve the baseline
- Units: Unit Code (single line text), Building (single line text), and Unit Notes (long text). “AL-4B” identifies this unit consistently.
- Tenancies: Tenancy Reference (single line text), Unit (linked record to Units), Start Date and End Date (date). Use “AL-4B-2026A” for this fictional occupancy.
- Inspectors: Name (single line text) and Email (email). This is the users table for the inspector portal.
- Inspection Items: Item Code and Item Label (single line text), Unit (linked record), and Room (single select). Examples are Kitchen counter and Kitchen cabinet handle. Retain identifiers if labels change.
- Visits: Visit Reference (single line text), Tenancy (linked record), Visit Type (single select: Move-in, Move-out, Supplement), Visited At (date with time), Inspector (linked record), and Review State (single select).
- Observations: Observation Number (autonumber), Visit and Item (linked records), Inspector (direct linked record), Observed Condition (single select), Description (long text), Photos (attachment), Recorded At (created time), Clarification (long text), and Capture State (single select: Working, Reviewed). Staff control Capture State.
- Comparisons: Tenancy and Item (linked records), Baseline Observation and Exit Observation (separate linked fields to Observations), Review Outcome (single select), Reviewer Notes (long text), and Reviewed On (date).
One item can have many dated observations. Each comparison pairs two particular observations for one tenancy; it does not simply fetch whichever photo was uploaded most recently. Suggested outcomes are Consistent evidence, Difference to review, Missing baseline and More information needed. None assigns liability.
Prepare the inspector’s workspace
Use Visits and Observations as portal data tables. Each needs its own direct Inspector relationship, following the users-table requirements. Priya creates the visit and its expected item observations in advance, populating both links. A relationship through Visit alone should not be treated as the required direct user field.
Set up email verification in Users & Login → Login Fields, using the inspector’s single email address. The login instructions explain the verification option. For every private table view, apply Personal records only (linked to the logged in user) under Filter and Sort → Choose Records to Display, as described in the record-scope documentation.
Expose editable condition, description and photo fields on the assigned capture records. Keep tenancy, item and review decisions under staff control. Create disjoint Working and Reviewed observation views filtered by staff-controlled Capture State. Working permits capture edits. In Reviewed, turn off Expand Records → Allow users to expand and edit records, following the view-level editing controls. Show condition, description and photos directly in the Reviewed grid; this route does not open another child form.
Priya can review directly in Airtable, avoiding a mixed inspector-and-manager editing surface. Disable creation, unlinking, deletion and duplication on the Reviewed route. Remove other editable views and linked-record expansion paths that could reach reviewed observations. Test old links and a previously opened capture session after staff changes Capture State. Do not rely on a status alone or claim globally read-only storage; stop rollout if another route still allows changes.
Capture the move-in visit completely
On the first visit, Morgan opens each expected item. For the counter, the description reads “Short pale mark beside the sink, visible in the close-up.” Morgan attaches a wider photograph for location and a close-up for detail. The cabinet handle has its own observation, marked No issue observed.
Do not record only damaged items. At move-out, a missing baseline could otherwise mean “no problem,” “not checked” or “forgotten entry.” Include Not inspected as a condition choice and require an explanation through the team’s review process. A blank record remains incomplete.
The attachment field’s Maximum allowed files setting can keep each observation manageable. Choose a limit that fits the inspection, explain which views are useful, and check the actual uploads. A file count cannot establish that the images show the correct room or date.
Priya checks the item coverage and image clarity, then changes each accepted observation’s Capture State to Reviewed and marks the visit Reviewed. The observations leave Working and appear in the non-editable Reviewed view. Later corrections become a Supplement visit with its own records and an explanation, rather than silently replacing the baseline photographs.
Pair the move-out evidence with the right items
When the tenancy ends, Priya creates a new Move-out visit and fresh observation records for the same item list. Morgan captures current conditions without editing the move-in visit. The counter has the familiar mark; the cabinet handle is now loose.
Priya creates a Comparison for each item, linking the exact move-in and move-out observations. For the counter, the outcome can be Consistent evidence with a short explanation. For the handle, choose Difference to review and record the next question. A difference does not explain its cause or decide who should pay.
If an item was replaced during the tenancy, record that context and link the relevant supplementary observation where available. Do not compare the old appliance’s photograph with its replacement as though they were the same physical item.
Handle missing and disputed evidence
Suppose the move-in bathroom photo is too blurred to show the surface being discussed. Keep it, mark Missing baseline or More information needed, and explain the limitation. Ask for available contemporaneous evidence through the manager’s normal process. Do not fill in an assumed “good condition” answer months later.
If a resident disagrees with a description, retain their dated statement separately, for example in an Evidence Notes table with Note (long text), Received On (date), Attachment (attachment), and Comparison (linked record). Staff decide what requires further review. This preserves two accounts without implying that either is automatically established fact.
Keep review and automation boundaries clear
This first version uses staff-created visit records, manual comparison links and human review. A separate automation could generate expected observations or remind a reviewer, but it needs its own mapping, duplicate handling and failure checks. Creating a date field or changing Review State does not itself send a message.
Before using real records, try two inspectors with different assigned visits. Check private access, baseline read-only behavior, photo placement, an uninspected item, a missing baseline and a supplement. Confirm the next tenancy cannot accidentally inherit the previous tenancy’s comparison. Test the shared experience, not only the builder.
The workflow fits teams that need organized condition documentation and a deliberate review handoff. It makes no promise of offline capture, tamper-proof evidence, automatic image comparison or legal sufficiency. Keep urgent repairs on the property’s established contact route, and keep financial decisions outside the inspection form.
