Problemet det løser: Regneark og post-it-lapper skalerer ikke. Ledere mister oversikten over hvem som er aktive, hvem som har utløpt, og hvem som faktisk er på hvilket team.

Hvordan det hjelper:

• Brukergrupper modellerer team, mannskaper, frivilliggrupper og organisatoriske enheter — alle med en utpekt leder og en medlemsliste.
• Medlemsperioder — hvert frivilliges medlemskap kan ha en start- og sluttdato, slik at sesong- eller vikarierende frivillige automatisk spores uten manuell opprydding.
• Ordnete lister — ledere vises alltid først, etterfulgt av medlemmer i en fornuftig visningsrekkefølge, noe som gjør det enkelt å se «hvem som har ansvaret» ved et øyekast.
• Hierarkisk organisering — grupper kan kobles inn i en større organisasjonsstruktur (via kategorier), slik at en «lydteam» kan være under et «produksjonsteam», som igjen er en del av en større arrangementsstruktur.
• Ingen betalingskompleksitet — i motsetning til butikk-/medlemsgrupper er grupper i People-modulen (Team, Crew, Volunteer, Organization) spesialbygget for koordinering, ikke handel, noe som holder opplevelsen enkel for frivilligkoordinatorer.

Den behagelige arbeidsdagen: Koordinatorer bruker mindre tid på å spørre «hvem er på dette teamet igjen?» og mer tid på å faktisk lede folk.

Hvorfor dette er viktig for organisasjonen din

Frivillighetsdrevne organisasjoner (kirker, ideelle organisasjoner, arrangementsprodusenter) lykkes eller sliter basert på hvor godt de kan se og administrere sine frivillige. En dedikert, ikke-kommersiell modell for planlegging av frivillige unngår å tvinge frivilligkoordinering gjennom et system designet for betalte medlemskap eller kunderegistre.

Tekniske detaljer

People-modulen er implementert i ExireNexus.Services/Services/UserGroupService.cs (IUserGroupService) mot modellene UserGroup og UserGroupMember i ExireNexus.Shared/Models.

Nøkkelpunkter i implementasjonen:

• UserGroup støtter en UserGroupType-enum (Team, Crew, Volunteer, Organization og kommersielle medlemskapstyper), slik at den samme underliggende tabellen og tjenesten kan betjene både koordinering av personer og brukstilfeller for betalt medlemskap uten å duplisere modeller.
• GetPeopleGroupsAsync(UserGroupType? groupType = null) henter ikke-slettede grupper, eventuelt filtrert etter type — det dedikerte inngangspunktet for People-modulen, holdt atskilt fra handelsorienterte medlemskapsspørringer selv om de deler samme tjeneste og tabell.
• Medlemskapsoppføringer (UserGroupMember) inneholder ActiveFrom / Expires-datoer, og GetGroupMembersOrderedAsync returnerer medlemmer sortert med ledere først, deretter etter visningsrekkefølge (ItemOrder), deretter navn — noe som gir Backstage UI en ferdig, fornuftig rekkefølge for medlemslisten uten sorteringslogikk på klientsiden.
• GetMembershipsForUserAsync og GetUserGroupsByUserIdAsync støtter omvendt oppslag — «hvilke grupper er denne personen i» — inkludert valgfri inkludering av utløpte medlemskap for historisk rapportering.
• GetOrganizationUnitsAsync returnerer alle organisasjonstype-grupper (med ledere og medlemmer forhåndslastet) slik at Backstage-organisasjonsbyggeren kan sette sammen et fullt hierarki på klientsiden uten N+1-spørringer.
• Hierarki utover gruppenivå oppnås via Category (selvrefererende gjennom ParentCategoryId), plattformens delte organisatoriske enhet, i stedet for å introdusere et separat hierarkibegrep kun for personer.

I tråd med plattformens arkitekturprinsipp ble frivillig-/personplanlegging lagt til som ny funksjonalitet i eksisterende UserGroupService i stedet for en parallell tjeneste — og beholdt én autoritativ kilde for alle gruppe- og medlemskapsdata.