Roles and application checklists
Defining what exists and what it takes to be approved.
The role catalog
/admin/roles is the CRUD for the nine (or however many, later) volunteer roles. Each role has:
- Slug — stable internal identifier (
sound,greeting,catechism, …). Don’t change slugs after a role is in use. - Name — display name on the site and in emails (“Sound”, “Greeting”…).
- Arrival time — what time volunteers in this role need to show up Sunday morning. Used in reminder emails and calendar events.
- Default slots per service — how many people to schedule in this role each Sunday (Greeting = 2, Catechism = 2, most others = 1). Overridable per service.
- Description — free-form. Shows up when a volunteer is applying.
- Display order — controls the order roles appear in review grids and pickers.
- Active — inactive roles don’t appear in the application form, generator, or pickers. Existing assignments aren’t removed.
Application checklists
Under each role is its application checklist — an ordered list of steps a new applicant has to clear to be approved.
Each step has:
- Label — what the applicant (and you) see (“Attended the intro meeting”, “Background check passed”).
- Self-attestable vs admin-confirmation-required — determines whether the applicant can check the step themselves or whether only an admin can.
Applicants see the checklist on their application page; admins see the same checklist on the applicant-review page. An application can only be approved once every step is checked.
Per-role eligibility rules
Beyond the checklist, some roles have prerequisite rules:
- Minimum tenure weeks — “must have been active for 8 weeks before being eligible for Sound.” Prevents brand-new volunteers from jumping to technically-sensitive roles.
- Requires other role first — “Catechism requires Greeting eligibility.” Forces a pathway.
- Preferred frequency cap — suggestion to the scheduler (“never more than every 3 weeks”). Soft by default, enforceable per-quarter via the generator’s strictness knob.
Archiving a role
Inactive roles are hidden from new applications but retained in history — past assignments still show up in the directory and audit log. Renaming a role is fine; changing its slug is not.