The pain it solves: Run sheets scattered across documents and printouts go stale the moment a room changes, a role gets reassigned, or a start time shifts — and nobody notices until it's too late.

How it helps:

• Run sheets tied to real events — build a structured, ordered sequence of items (segments, cues, tasks) for a specific occurrence of an event, so the schedule always reflects the actual date and time it applies to.
• Reusable templates — save a run sheet as a template once, then apply it to any future occurrence instead of rebuilding the same structure from scratch every week.
• Roles with self-service sign-up — assign roles to specific people, or leave them open for self-signup, with the ability to accept, decline, or claim a role directly.
• Equipment tracking per item — attach the equipment each segment needs, so gaps are visible before the event starts rather than discovered mid-run.
• Draft vs. published — schedules can be worked on privately and published only when ready, keeping in-progress planning invisible to the people it isn't ready for yet.

The happy workday: The person running the event opens one published, up-to-date run sheet — no version confusion, no "wait, who has the projector?" moment.

Why This Matters for Your Organization

Volunteer Resource Planning answers "who's on the team"; Scheduling answers "what happens, when, and with what" for any specific event occurrence — together they cover both the people side and the execution side of running events reliably, without forcing either concern into the other's data model.

Technical Details

Scheduling is implemented by EventScheduleService (ExireNexus.Services/Services/EventScheduleService.cs, IEventScheduleService) against the EventSchedule, EventScheduleRole, EventScheduleItem, EventScheduleItemEquipment, and EventScheduleAttachment models (ExireNexus.Shared/Models/Scheduling).

Key implementation points:

• EventSchedule doubles as both a concrete run sheet (linked to an Event and a specific OccurrenceStartTime) and a reusable template (IsTemplate = true, unlinked from any specific event) — one model serves both cases rather than duplicating the schedule structure.
• CreateAsync(eventId, occurrenceStartTime, templateId) can optionally seed a new run sheet from an existing template, and GetTemplatesAsync/SaveTemplateAsync/DeleteTemplateAsync manage the template library independently from live schedules.
• ReorderItemsAsync persists the display order of run-sheet items directly, keeping ordering logic in the service rather than the UI.
• Volunteer-facing role management — AcceptRoleAsync, DeclineRoleAsync, SignUpForOpenRoleAsync — lets assigned people confirm or release a role, and lets open, self-signup-enabled roles be claimed directly, returning a ScheduleRoleResult so the UI (ExireNexus.Backstage/Components/Editors/Scheduling/ScheduleEditor.razor, ScheduleList.razor) can reflect success/failure without throwing for expected conditions (e.g., a role already taken).
• GetMyUpcomingRolesAsync and GetOpenRolesAsync scope role queries to published, upcoming occurrences only — draft schedules never surface roles to volunteers before a leader publishes them (IsPublished/PublishedDate).
• Scheduling is a separately activatable module (SettingNames.ModuleScheduling) from the People module used by Volunteer Resource Planning, so an organization can adopt run-sheet planning independently of (or alongside) volunteer/team coordination.