The pain it solves: Spreadsheets and sticky notes don't scale. Leaders lose track of who's active, who's expired, and who's actually on which team.

How it helps:

• User Groups model teams, crews, volunteer groups, and organizational units — all with a designated Leader and a roster of members.
• Membership windows — each volunteer's membership can have an active-from and expiry date, so seasonal or rotating volunteers are automatically tracked without manual cleanup.
• Ordered rosters — leaders always appear first, followed by members in a sensible display order, making it easy to see "who's in charge" at a glance.
• Hierarchical organization — groups can be linked into a larger organizational structure (via categories), so a "Sound Crew" can sit under a "Production Team," which sits under a bigger event structure.
• No payment complexity — unlike shop/membership groups, People-module groups (Team, Crew, Volunteer, Organization) are purpose-built for coordination, not commerce, keeping the experience simple for volunteer coordinators.

The happy workday: Coordinators spend less time asking "who's on this team again?" and more time actually leading people.

Why This Matters for Your Organization

Volunteer-driven organizations (churches, non-profits, event producers) succeed or struggle based on how well they can see and manage their people. A dedicated, non-commercial people-planning model avoids forcing volunteer coordination through a system designed for paid memberships or customer records.

Technical Details

The People module is implemented in ExireNexus.Services/Services/UserGroupService.cs (IUserGroupService) against the UserGroup and UserGroupMember models in ExireNexus.Shared/Models.

Key implementation points:

• UserGroup supports a UserGroupType enum (Team, Crew, Volunteer, Organization, and commercial membership types), letting the same underlying table and service serve both people-coordination and paid-membership use cases without duplicating models.
• GetPeopleGroupsAsync(UserGroupType? groupType = null) retrieves non-deleted groups, optionally filtered by type — the dedicated entry point for the People module, kept separate from commerce-oriented membership queries even though they share the same service and table.
• Membership records (UserGroupMember) carry ActiveFrom / Expires dates, and GetGroupMembersOrderedAsync returns members ordered leaders-first, then by display order (ItemOrder), then name — giving Backstage UI a ready-made, sensible roster order without client-side sorting logic.
• GetMembershipsForUserAsync and GetUserGroupsByUserIdAsync support the reverse lookup — "what groups is this person in" — including optional inclusion of expired memberships for historical reporting.
• GetOrganizationUnitsAsync returns all organization-type groups (with leaders and members eagerly loaded) so the Backstage organization builder can assemble a full hierarchy client-side without N+1 queries.
• Hierarchy beyond the group level is achieved via Category (self-referencing through ParentCategoryId), the platform's shared organizational entity, rather than introducing a separate hierarchy concept just for people.

Consistent with the platform's architecture principle, volunteer/people planning was added as new capability on the existing UserGroupService rather than a parallel service — keeping a single authoritative source for all group and membership data.