You can use Airtable and miniExtensions to collect tenant maintenance requests, keep each repair linked to the right unit, and give tenants a place to check progress. The useful part is connecting the original report, later visits and the final closure decision, so a second visit does not erase what happened during the first.

This example is for a small property team handling routine repairs. It uses fictional tenant Maya Chen in Cedar Court, unit 2B, who reports a kitchen tap that drips after use. The suggested tables and status labels are a workflow design you can adapt, not a packaged maintenance system or a tested customer installation.

Define what the portal should handle

The tenant needs to describe the issue, attach a useful photo, explain when staff can contact them and see the latest approved update. The coordinator needs to check the location, decide the next action and assign a person to follow through. A technician needs a work brief and a way to report observations. Those are different responsibilities, even when one person fills two roles.

Put an emergency notice above routine intake. State your actual urgent-contact route and when it is monitored. Do not invite tenants to rely on a form for immediate danger, an active emergency or urgent assistance. A submitted record alone does not dispatch a contractor or guarantee a response time.

The broader property management guide covers listings, leases and owner information. This workflow focuses on one narrower outcome: knowing what happened to a reported repair and what should happen next.

Separate the request from repair visits

  • Tenants: Tenant Name (single line text), Email (email), and Current Unit (linked record to Units). Keep one intentional login identity per tenant, rather than treating an apartment number as a personal identity.
  • Units: Unit Label (single line text), Building (single line text), and Current Tenants (linked records to Tenants). Cedar Court 2B is a location record, not a repair.
  • Repair Requests: Request Number (autonumber), Tenant (linked record to Tenants), Reported Unit (linked record to Units), Issue Summary (single line text), Description (long text), Photos (attachment), Contact Preference (single select), Submitted At (created time), Tenant Update (long text), and Status (single select).
  • Repair Visits: Visit Reference (single line text), Request (linked record to Repair Requests), Planned Date (date with time if needed), Actual Date (date), Assigned Person (single line text), Findings (long text), Work Performed (long text), and Outcome (single select).

Use request statuses such as New, Reviewing, Visit Being Arranged, Work in Progress, Awaiting Follow-up and Closed. These are labels maintained by your team. Add a staff-only Next Action and Next Action Owner to the request. A visit outcome of “replacement part required” should leave the request open, with a concrete next action.

Keep Reported Unit on the request even if the tenant later moves. Otherwise a lookup of the tenant’s current unit can make an old repair appear to belong somewhere else. Staff should verify the unit association when reviewing intake.

Give the tenant a focused request view

In a miniExtensions Portal, choose Repair Requests as the data table and Tenant as its linked user field. The users-table documentation explains how the selected relationship connects the displayed records to the login identity. Any additional tenant-facing table needs its own appropriate link to Tenants.

For private access, open Users & Login, select the email under Login Fields, and enable Two-Factor Authentication (Email verification). Each user record needs one valid email address, not a shared list. Follow the email-verification setup; typing a known email alone should not be your access check.

Review every exposed private table and every view: under Filter and Sort, set Choose Records to Display to Personal records only (linked to the logged in user). Follow the record-scope instructions. Keep each record linked to the actual intended user, then verify access with both fictional users.

Keep the first version simple: show the request summary, submitted date, tenant-facing status and latest Tenant Update. Let tenants create requests and provide the issue details, but keep internal assignment, cost estimates and closure decisions out of their editable form. Keep technician administration in Airtable or a separately configured staff experience.

Create Airtable views for Open Repairs and Repair History, then select them in the portal’s Tables → Views → Filter and Sort settings. Predefined portal views can organize the queue, but a convenient view is not a substitute for verifying record access. Check that the chosen configuration is not displaying everybody’s requests.

If photographs help triage, give the upload field a clear description: show the problem area and omit unrelated people or personal documents. The documented attachment-type setting can limit uploads to appropriate types. A file being accepted does not prove that it is a useful or safe repair photograph.

Walk one repair through the handoffs

Maya submits “Kitchen tap keeps dripping,” adds one close-up image and asks to be contacted about an appointment. The coordinator checks that the request is linked to Maya and unit 2B, reads the report and changes the status to Reviewing. They record who will arrange the next step.

After contacting Maya through the team’s normal channel, the coordinator creates a Repair Visit linked to the request. The tenant-facing update might say “We are arranging a visit; we will contact you to agree a time.” Do not show a tentative internal date as a confirmed appointment.

The first visit finds a worn component that cannot be replaced immediately. Record that visit’s findings and outcome, then create a separate follow-up visit when the part is available. Keep the request in Awaiting Follow-up and explain the next step in plain language. Preserving both visits makes it possible to understand why the issue remained open.

After the second visit, staff record the work performed and review whether further follow-up is required. A designated coordinator makes the closure decision and records a closure date and tenant-facing summary. If you request tenant confirmation, describe how that response is handled rather than assuming silence proves the repair worked.

Handle repeat reports and changing occupancy

If Maya reports the same drip again, staff should first decide whether this is a continuation or a new problem. Keep the new evidence and relate it to the earlier request. Do not delete the later report merely because its title looks similar, and do not overwrite the original findings to make the history appear simpler.

Occupancy changes need their own review. A new tenant should not automatically inherit the previous tenant’s personal repair messages. Decide which property-level maintenance facts staff retain and which tenant-facing history remains associated with the original requester. Review access when a tenant leaves.

Check the experience before sharing it

  • Create two fictional tenants with different units and requests. Check both published end-user experiences, not just the builder preview.
  • Confirm each tenant can see the intended requests and cannot change staff decisions or browse another tenant’s records.
  • Submit a test request and inspect its actual Tenant and Reported Unit links in Airtable.
  • Add two visits and confirm the first visit’s evidence remains intact.
  • Try an unlinked request. Use the missing-records troubleshooting guide to distinguish an incorrect relationship from a view filter.
  • Close a test request and verify the history view and visible closure summary.

This approach fits teams that want structured repair intake and a clear record of follow-through. If you need emergency dispatch, contractor scheduling, legally specified notices or guaranteed service-level enforcement, evaluate those requirements separately. Reminders, emails and escalation rules require an explicitly configured process; the tables and portal do not create them by themselves.