You can collect volunteer hours in Airtable by giving each service entry its own record, linking it to a volunteer and project, and keeping coordinator-reviewed hours separate from the volunteer’s original report. A miniExtensions Portal gives volunteers a place to submit entries and see which ones still need clarification.

This is useful for community programs that currently receive a mixture of spreadsheets and messages at the end of each month. The example below uses fictional adult volunteers at Harbor Community Projects. It focuses on service reporting and coordinator review, with no payroll, tax substantiation or certified-attendance claim.

Keep the report and the review separate

Jamie reports three hours spent assembling event materials on 8 May. The coordinator’s attendance sheet indicates a two-and-a-half-hour session. If staff simply replaces three with 2.5, the team loses the distinction between what Jamie submitted and what staff accepted. Instead, preserve Reported hours and add Reviewed hours, a Review outcome and an explanation.

Decide the reporting convention before building the form. Does time include setup? Are breaks excluded? Is travel counted? Put a short, program-specific instruction above the hours input. These are organizational decisions, not built-in miniExtensions rules. A consistent definition prevents more confusion than a complicated form that leaves the meaning of an hour unstated.

Model service entries and corrections

  • Volunteers: Volunteer name as primary single-line text, Email as email, and Active as a checkbox.
  • Projects: Project name as primary text, Coordinator as text, Reporting instructions as long text, and Accepting entries as a checkbox.
  • Service entries: Entry reference as primary text; Volunteer and Project as linked-record fields; Service date as a date; Activity as long text; Reported hours and Reviewed hours as decimal numbers; Review outcome as a single select; Coordinator explanation as long text; Reviewed on as a date.
  • Corrections: Correction reference as primary text; Service entry and Volunteer as links; Proposed hours as a decimal number; Explanation as long text; Correction state as a single select; and Submitted at as created time.

Suggested Review outcome choices are Submitted, Clarification requested, Accepted and Not counted. Keep the correction state separate: a request for a correction can be Pending even when the original entry was previously accepted. Every portal-visible correction needs its direct Volunteer link, not just an indirect connection through the service entry.

Give volunteers a focused submission experience

Start with Service entries as the Portal’s Data Table and Volunteer as the User Field. Build the Airtable links before setup; the Users Table guide explains the required direct relationships.

Let the volunteer enter the service date, project, activity and reported duration. Keep Reviewed hours, review outcome and coordinator explanation outside volunteer editing. For the project picker, offer only the intended existing projects and prevent volunteers from creating or changing project records through an expanded form. Review the actual picker and expansion settings rather than relying on a short list of preview fields.

Use an authenticated access method appropriate for personal records. The login documentation recommends email verification. A person’s name selected from a list should not be treated as proof of identity. On personal entry views, select Personal records only (linked to the logged in user).

Use a normal record-list view with record creation configured if volunteers need both history and submission in one table. A Portal Form view is creation-only and cannot coexist with other views on that same table, as the view-type guide explains. Avoid designing a history tab that the selected view mode cannot provide.

Put accepted service entries in a separate history view and route changes through Corrections, rather than leaving original values editable. Under the view’s Expand Records settings, turn off Allow users to expand and edit records. The record-editing guide explains that this affects that view, not every access path. Check other views plus creation and unlinking controls. Test that historical values cannot change through any exposed route.

Review the month without counting everything twice

Create a staff review view for Submitted entries. The coordinator checks the date, project, activity and duration against whatever evidence the program normally uses, then records reviewed hours and a reason for material differences. A positive number submitted through a form is still a self-report.

For Jamie’s entry, staff asks whether the extra half hour was approved preparation work. Jamie supplies the context in a correction record. If it qualifies under the program’s rules, staff accepts three hours and records why. Otherwise, staff records 2.5 reviewed hours and explains the exclusion. Neither route requires erasing the original three-hour report.

Build monthly summaries from accepted reviewed hours, not from a mixture of Reported hours and Proposed hours. Review any Airtable formulas or rollups with a small sample before sharing totals. Make the period visible in the report: service month and review month can differ when a late correction arrives.

Handle duplicates and late entries deliberately

Suppose Jamie submits the same event twice because the first submission appeared slow. Flag the suspected duplicate for review by matching volunteer, date, project and activity. A matching date alone is insufficient because someone may legitimately work two sessions. Keep the second record with a clear review outcome rather than silently adding both to the total.

A late entry should carry its actual service date. Staff can decide whether to include it in a revised summary or the next reporting cycle, while preserving that distinction. Notifications and monthly reminders require a separate process or explicitly configured automation; this design does not send them automatically.

Check the complete reporting cycle before rollout

Test two fictional volunteer accounts, including entry creation, a clarification, a correction, an accepted entry and a duplicate. Confirm that each account sees only its intended history and cannot alter staff decisions or link a correction to another volunteer’s entry. Reload the saved Airtable records and compare a manually calculated sample total with the summary.

For future scheduling rather than past service, use the separate volunteer availability workflow. Keeping these records apart helps a coordinator distinguish offered time, assigned time and reviewed service. The result is a clearer reporting queue, not an assertion that every submitted hour has been independently verified.