A cleaning completion queue in Airtable can connect each scheduled visit to its checklist responses, supporting photos and any follow-up work. A miniExtensions portal gives cleaners a focused place to report their assigned checks, while a supervisor separately records whether the visit is accepted. That separation keeps “reported complete” from being mistaken for “inspected and accepted.”

This fictional example follows a small team cleaning three shared office locations. At Maple House, the evening cleaner finishes most tasks but reports a stain in a meeting room. The supervisor needs to see that exception, request specific rework and verify the result. The workflow below is a proposed setup, not a tested deployment or a substitute for a safety or regulated inspection process.

Make every visit a separate job

Start with five tables:

  • Locations: Location name as single-line text and Service notes as long text. Keep notes limited to operational information appropriate for the intended users.
  • Cleaners: Name as single-line text and Email as an email field, with one record per portal user.
  • Jobs: Job reference as text, Location and Assigned cleaner as linked-record fields, Scheduled date as a date, Reported state as a single select, and Supervisor outcome as another single select.
  • Checklist responses: Job and Assigned cleaner as linked-record fields, Check description as long text, Result as a single select, Cleaner note as long text, and Evidence as an attachment field.
  • Rework: Job, Checklist response and Assigned cleaner as linked records, Requested correction as long text, Completion note as long text, Evidence as an attachment, and Supervisor review as a single select.

Create a new Job for each visit, such as “Maple House / November 12 / evening.” Do not reuse yesterday’s job by changing its date. Keep checklist descriptions specific enough to evaluate: “Meeting-room tables wiped” is more useful than “Room done.” The coordinator manually prepares the response records for each job in this design.

Give cleaners a practical reporting view

Use Checklist responses as a portal data table, with Assigned cleaner as its direct link to the Users table. The Users table guide describes the required relationship. A link through Job alone should not be assumed to provide the direct user association for each displayed table.

For every cleaner-facing view, select Personal records only (linked to the logged in user) in Choose Records to Display. Use the personal-record filtering instructions. Test each enabled view with separate fictional cleaner accounts before introducing real operational data.

Display the job reference, location, scheduled date, check description, Result, note and photo field. Suggested Result choices are Complete, Issue found and Not done. Those labels are your checklist design. Staff should define what each means so cleaners do not use Complete to mean “I attempted it.”

Keep supervisor-only decisions outside the cleaner’s editable form. If a different employee takes over a visit, the coordinator must review the user links on the job, checklist responses and open rework records rather than assuming that updating one parent field changes access everywhere.

Collect useful evidence without making every check burdensome

For ordinary checks, a result may be enough. For an exception, ask for a short description and a relevant photo when appropriate. For example: “Stain remains on the meeting-room table after the normal cleaning procedure.” Avoid photographing people, computer screens, private paperwork or unrelated office contents.

miniExtensions supports a Maximum allowed files setting for attachment fields. The upload-limit documentation explains that existing attachments count toward the limit. If an evidence field already contains two files and allows three, only one additional file fits. A limit does not establish that the photos are accurate, timely or sufficient.

Have the cleaner report the job as submitted for review only after checking the assigned response records. The coordinator or supervisor reviews the actual results, including Not done and Issue found entries. This design does not assume that a status formula can assess the quality of the work or that all required records are automatically created.

Create rework against the exact failed check

The supervisor reviews Maple House’s meeting-room response and creates a Rework record linked to that response and the original Job. The requested correction should say what needs attention and how the result will be assessed. Assign it to the responsible cleaner through the direct user link.

Expose Rework as a separate portal table only after configuring and checking its own user relationship and personal-record views. The cleaner adds a completion note and a new evidence photo. The supervisor then reviews the result and records Accepted or Further work needed. Saving the completion note alone does not constitute acceptance.

If another attempt is required, keep the prior submission and create a clearly labeled next rework round. That preserves the operational sequence instead of replacing the first photo with a better-looking one. It is still ordinary editable recordkeeping, not an immutable audit log. Choose a different system if formal evidence retention requirements demand capabilities this setup has not established.

Keep review, scheduling and safety responsibilities clear

A supervisor can use Airtable views to find submitted jobs with unresolved responses and rework awaiting review. After checking the actual records, they update Supervisor outcome. A job can be reported complete while awaiting acceptance; displaying both fields makes that distinction visible.

Recurring schedule creation, reminders and escalation are separate processes. This example uses coordinator-created jobs and manual follow-up, so it does not imply that those actions happen automatically. Urgent hazards should follow the organization’s actual reporting procedure rather than waiting in an ordinary cleaning review queue.

The workflow also does not promise offline operation, GPS verification, route optimization or proof that a cleaner was physically present. Test the portal on the devices and connections the team will use. Decide what staff should do when connectivity prevents submission, then reconcile the record later without inventing a completion timestamp.

Test a full visit and a failed inspection

  • Create a fictional job with three checks and verify each assigned cleaner’s visible records.
  • Save one Complete result, one Issue found result and one Not done result; reload and check persistence.
  • Create rework linked to the correct job and failed response, then verify the cleaner can find it.
  • Submit completion evidence and confirm the supervisor’s acceptance remains a separate action.
  • Create the next day’s job and verify yesterday’s responses and evidence remain attached to yesterday’s visit.

This design is most useful when the operational problem is the handoff from reported work to supervisor acceptance. It keeps recurring service visits, concrete exceptions and corrective work distinct, rather than treating a checked box as the end of the job.