Reviewing applicants

Turning a signup into an active volunteer.

The flow

Someone signs up → their account is applicant status. They apply to a role → an applications record opens with status open. You review → either approve (they’re eligible for that role from now on), reject (with reason; they can reapply), or request info (emails them).

The checklist

Each role has its own application checklist, defined in Roles. Steps look like:

• “Attended the intro meeting” — might be self-attestable.
• “Background check passed” — admin-confirmation required.
• “Shadowed a Sunday” — admin-confirmation required.

On an application’s page you see every step with a checkbox and a notes field. Self-attestable items may already be green (the applicant ticked them themselves); admin-required items start unchecked. Approve is disabled until every required item is green.

Bulk approve

For roles where every checklist item is self-attestable and the applicant has checked them all, the queue offers a Bulk approve button for those applications. Use sparingly — the checklist exists to make sure you’ve had the conversation.

What approval actually does

• Writes a role_eligibility row for (user, role).
• Flips the user’s status from applicant to active if this is their first approved role.
• Fires a welcome email (for first-role approvals) or a role-added confirmation (for subsequent roles).
• Starts including them in future quarter drafts for that role. It doesn’t retroactively add them to an already-published quarter — you’d reassign in the admin quarter editor if you want to slot them in mid-quarter.

Rejection

Requires a reason (shown to them in the email). Rejected applications stay in the history; the applicant can reapply to the same role later.

Audit trail

Every state change — approve, reject, checklist tick, reassignment — writes an audit_log row with who did it and when. Visible at /admin/audit.