Initiate Temporary Pause as Peer Mentor
Peer mentors need a lightweight way to signal that they are temporarily unavailable without going through a full offboarding process. The pause action should be accessible from their profile or home screen, present a confirmation dialog with an optional expected return date, and immediately notify the responsible coordinator. During the pause the mentor should no longer appear in active matching pools or be assigned new contacts, but all historical data and certification records must remain intact.
User Story
Audience Summaries
This high-priority story directly addresses volunteer churn — one of the most costly challenges for peer-support programmes run by NHF and HLF. Without a formal pause mechanism, peer mentors who need a temporary break disengage entirely and eventually unregister, forcing costly re-onboarding and certification cycles. By offering a lightweight, self-service pause action, the platform retains trained volunteers, preserves their historical data and certifications, and protects the organisation's capacity to serve contacts. Both NHF and HLF explicitly requested this feature, making it a key differentiator for contract retention and expansion.
Reducing permanent churn by even a small percentage translates directly into lower recruitment and training costs, higher volunteer lifetime value, and a more resilient programme that can maintain consistent contact-to-mentor matching quality throughout the year.
Delivering this high-priority story requires coordination across mobile UI, backend status management, notification infrastructure, and offline-sync components. Effort is moderate-to-high: the confirmation dialog, status toggle, coordinator push/in-app notification, and offline queue all represent discrete implementation tasks that span at least two squads. Acceptance criteria are well-defined and cover happy path, cancellation, offline behaviour, and roster visibility — making UAT straightforward but requiring dedicated test environments with simulated offline conditions. Dependencies include the notification service being stable and the coordinator roster view being available for verification.
Rollout should be gated behind a feature flag to allow phased release per chapter. Risk areas include notification delivery reliability on low-connectivity devices and ensuring the offline queue does not create duplicate status events on reconnect.
Implementation requires changes across four layers. On the data layer, the peer_mentor or user_profiles table needs a status field supporting at least 'active', 'paused', and 'inactive' states, plus an optional expected_return_date column. The matching pool query must filter out paused mentors. On the API layer, a PATCH /mentor/status endpoint is needed with validation and optimistic locking to prevent race conditions.
The notification layer must dispatch both in-app and push events to the responsible coordinator on status change — ensure idempotency so offline queue retries do not send duplicate alerts. On the client, the toggle component must update local state immediately for perceived performance, then reconcile with the server response. The offline sync queue (likely using a local SQLite or AsyncStorage job table) must serialise the status mutation and replay it on reconnect. Edge case: if two status mutations are queued offline, only the latest should be applied.
No data migration needed; historical records remain untouched.
Acceptance Criteria
- Given I am logged in as a peer mentor, when I tap the pause/reactivate toggle on my profile, then a confirmation dialog appears explaining what pausing means and asking me to confirm
- Given the confirmation dialog is shown, when I confirm the pause, then my status is set to paused in the system and the toggle reflects the new state immediately
- Given I have confirmed the pause, when the status update is saved, then the coordinator responsible for my chapter receives an in-app and push notification informing them that I have paused
- Given my status is paused, when a coordinator views the peer mentor roster, then I appear with a clear visual pause indicator rather than being hidden entirely
- Given my status is paused, when the app is offline, then the pause action is queued and synchronised as soon as connectivity is restored
- Given I tap pause but then tap cancel in the confirmation dialog, then no status change occurs and no notification is sent
Business Value
Voluntary temporary pauses reduce permanent churn. Without a formal pause mechanism peer mentors who need a break tend to stop engaging entirely and eventually unregister. Retaining their profile, history, and certification preserves organisational capacity and avoids re-onboarding costs. NHF and HLF both explicitly requested this feature to protect their volunteer base.
Components
- Pause / Reactivate Toggle ui
- Pause Confirmation Dialog ui
- Pause Status Banner ui
- Mentor Status Service service
- Coordinator Notification Service service
- Mentor Status Repository data
- Mentor Status BLoC infrastructure
- Pause Status Indicator ui
- Pause Management Service service
- Pause Notification Service service
- Peer Mentor Status Repository data
- Pause Status Notification Card ui
- Pause Notification Orchestrator service
- Pause Notification Payload Builder service
- Pause Status Record Repository data
- FCM Notification Dispatcher infrastructure