The pain it solves: Different "kinds" of people (employees, volunteers, members, contractors) usually end up in different tools, none of which talk to each other.

How it helps:

• One underlying People model (Users, Customers, and User Groups) supports every kind of resource — staff hierarchies, volunteer teams, member cohorts — without separate systems.
• Group types distinguish teams, crews, and organizational units, so the same planning tools work whether you're scheduling a Sunday morning crew or a project team.
• Leader-based structure gives every group clear ownership and accountability, with leadership visible directly in the roster.
• Membership windows (start/expiry dates) make temporary assignments, rotations, and seasonal resourcing effortless to track — no manual "remove them next month" reminders needed.
• Because groups can nest under categories, resource planning scales from a two-person team to a multi-department organization without changing tools.

The happy workday: One place to see who's available, who's assigned, and who's leading — for every type of resource in the organization.

Why This Matters for Your Organization

Consolidating all people-resource planning into one model avoids the classic problem of duplicated, drifting records across HR spreadsheets, volunteer sign-up tools, and membership databases. Everyone — staff or volunteer — is represented consistently.

Technical Details

Resource planning for people spans three cooperating models in ExireNexus.Shared/Models:

• ApplicationUser — the identity entity (extends ASP.NET Identity's IdentityUser<Guid>), representing anyone who logs in.
• Customer — the external "people" entity, covering shop customers, members, and CRM contacts, optionally linked to an ApplicationUser when the person also has login access.
• UserGroup / UserGroupMember — the grouping entity, with a Leader (ApplicationUser) and typed membership rows (UserGroupMember) that carry ActiveFrom/Expires windows, exposed through IUserGroupService (ExireNexus.Services/Services/UserGroupService.cs).

Because groups are typed via the UserGroupType enum rather than separate tables, the same service methods (GetGroupMembersOrderedAsync, GetMembershipsForUserAsync, UpdateUserGroupMembers) serve staff planning, volunteer coordination, and membership administration alike. Category (self-referencing via ParentCategoryId) provides the organizational hierarchy layer on top, letting any group be nested under a department, event, or larger organizational unit without a bespoke tree structure per feature.

This reflects the platform's core design principle: reuse existing multi-purpose entities with type discriminators rather than building a parallel system per resource type.