Bulk Actions
Feature Detail
Description
Provides organization administrators with the ability to apply actions - deactivation, role change, or invitation resend - to multiple selected users in a single operation. Designed for managing large volunteer cohorts during onboarding waves or organizational restructures where many users require the same change simultaneously. The feature includes a checkbox selection interface, a confirmation step showing the count of affected users, and per-record result reporting after execution.
Sources & reasoning
The blueprint marks bulk-actions v1.0 (not MVP), consistent with it building on top of stable single-record CRUD. NHF's organization scale (1,400 local associations) makes individual-record management impractical for any restructure, justifying the feature as a should_have for v1.0. No source passage places bulk user actions in Phase 1, so MVP is not warranted.
No source references — this artifact was included based on reasoning alone (see above).
Analysis
NHF alone spans 12 national associations, 9 regions, and 1,400 local associations. Without bulk actions, an org admin performing a restructure must edit each user record individually - hours of repetitive work that increases the risk of partial changes leaving the system inconsistent. Bulk deactivation is especially critical during membership transitions when many volunteers exit simultaneously. Reducing administrative friction for large organizations directly supports the platform's goal of making peer mentor management as low-effort as possible, and was a cross-cutting concern raised in workshop notes across multiple organizations.
The bulk action UI layers onto the existing user list with a sticky checkbox column and an action toolbar that activates when one or more rows are selected. Each bulk operation dispatches a single batched API call that processes records server-side within a transaction, returning a per-record result array displayed as success and failure counts inline. Selections exceeding 100 users are submitted as background jobs with server-sent-event progress updates so the admin can navigate away and return. The backend applies identical authorization checks as individual actions - bulk deactivation cannot target users with a higher privilege level than the requesting admin.
Components (46)
Shared Components
These components are reused across multiple features
Service Layer (11)
Data Layer (23)
Infrastructure (7)
User Stories
No user stories have been generated for this feature yet.