You can collect training attendance corrections in Airtable without letting a learner’s self-report overwrite the attendance register. Keep the original attendance entry, create a separate correction request, and ask a coordinator to compare it with the trainer’s evidence before making a change.

This workflow suits adult professional development programs with occasional missing check-ins, name mismatches or partial-session disputes. Its outcome is a reviewable correction tied to one learner and one session. It does not verify attendance automatically, assess competence or award completion certificates.

Separate the register from the request

Imagine a fictional training provider, Cedar Learning, running a two-session workshop for adult participants. Morgan attended the morning workshop but appears as absent because the sign-in entry used a shortened name. Morgan needs to explain the discrepancy, not edit the trainer’s register directly.

Use four tables:

  • Learners: Learner Code (single line text, primary), Name (single line text) and Email (email).
  • Sessions: Session Code (single line text, primary), Title (single line text), Session Date (date) and Trainer (single line text).
  • Attendance: Attendance Code (single line text, primary), Learner (link to Learners), Session (link to Sessions), Recorded Attendance (single select: Present, Partial, Absent, Not recorded), Recorded Minutes (number), Register Notes (long text) and Reviewed At (date with time).
  • Correction Requests: Request Code (autonumber), Learner (link to Learners), Session Code Supplied (single line text), Attendance Entry (link to Attendance, maintained by staff), Claimed Attendance (single select), Claimed Minutes (number), Explanation (long text), Submitted At (created time), Review Status (single select: New, Checking, Accepted, Declined, More information), Reviewer Notes (long text) and Decision Date (date).

The Attendance Entry link identifies the register entry being reviewed. Leave staff responsible for assigning it if you have not configured and tested a learner-specific picker. A visible session code is enough for initial intake; exposing a dropdown of everybody’s attendance entries is not necessary.

Give learners a focused submission route

For participants who need multiple requests, a miniExtensions Portal fits the one-learner-to-many-requests relationship. The login documentation explains the Users-table model and linking records to users. Configure Learners as the users table and expose Correction Requests through its learner relationship. Review the login method and record visibility before inviting anyone.

A Form view can provide new-request intake. In a portal, records created through that view are linked to the logged-in user by default; see the view-type documentation. A table using Form view cannot also have other views. If learners need a request list as well, choose a list-based portal table with an appropriate creation form instead of assuming the Form view doubles as a history screen.

Ask for the session code, the attendance the learner believes is correct, the approximate minutes and an explanation. Keep Review Status, Attendance Entry and decision fields out of the submission form. This is a proposed workflow, not a claim that omitting fields alone establishes every access restriction. Test all exposed views and linked-record selectors with two different learner accounts.

Make the discrepancy understandable

Provide a short instruction: “Tell us which session needs review and why the attendance entry may be wrong. The training team will check the register before changing it.” Avoid success messages saying “Attendance corrected.” A saved request is only confirmation that the request was received.

Morgan submits the morning session code, selects Present and explains the shortened name. The coordinator matches the request to the correct Attendance entry and changes Review Status to Checking. Morgan’s explanation remains on the request, while the register still says Absent until review finishes.

Where a learner can view their recorded attendance, show the current value separately from the claimed value. Do not label a learner-editable field “Verified attendance.” For an occasional low-sensitivity correction on an existing record, the separate record correction tutorial explains a direct-link approach. The request-table design here serves a different need: preserving multiple attendance disputes and their decisions.

Review evidence and record the decision

The coordinator checks the trainer’s register, relevant check-in evidence and any follow-up. If the evidence supports Morgan’s request, staff update Recorded Attendance, enter the reviewed minutes if applicable, and record the decision on the request. If it does not, staff leave the register unchanged and explain the reason in appropriate learner-facing wording.

These are manual steps. A status field does not perform an investigation or synchronize the register. If you later add an automation, define exactly which approved values it may copy and how to prevent duplicate changes. Keep a reviewer responsible for deciding whether the evidence is sufficient.

Handle duplicates and partial attendance carefully

If Morgan submits twice, link both requests to the same Attendance entry and mark one as a duplicate in staff notes. Do not create another register row simply to accommodate the second request. If the claim concerns only the morning portion of an all-day event, review the minutes or session boundary rather than changing the whole day to Present.

A disputed entry can remain More information without implying the learner failed the course. Attendance, training completion and certification are separate decisions. This small workflow is not a learning management system or a tamper-proof audit ledger.

Check the complete handoff before launch

Publish the extension before using its end-user link; configuration changes require publishing again, as described in sharing an extension. With fictional adult records, submit a correction, confirm its learner relationship, and verify that the original register remains unchanged. Test a second learner, a repeated request and a declined correction.

Finally, have a coordinator complete one accepted request and inspect both records. The expected result is a documented discrepancy, an explicit human decision and a corrected register only where justified. These are acceptance checks for your implementation, not reported test results.