Reactivate After a Pause Period
A paused peer mentor should be able to self-reactivate directly within the app. The reactivation flow should be as simple as the pause flow: a toggle or button, a brief confirmation, and immediate status update. Upon reactivation the coordinator should receive a notification, the mentor should re-appear in the active roster and matching pool, and the pause status banner visible during the paused period should be dismissed. The flow must also check certification validity at the point of reactivation and warn the mentor if their certification has expired or is about to expire.
User Story
Audience Summaries
Reactivation is the mirror of pause and carries equal strategic weight. If returning to active status is cumbersome or requires coordinator intervention, paused mentors will delay coming back or disengage permanently. This story removes that friction entirely with a self-service flow that mirrors the simplicity of pausing, reducing the coordinator's administrative burden while shortening inactive periods. For NHF and HLF, faster reactivation directly improves volunteer utilisation rates and matching capacity.
The built-in certification expiry check adds proactive compliance value — coordinators are notified of expiring certifications at the moment of reactivation rather than discovering the issue after a mentor has already been assigned to a contact. This protects programme quality, reduces compliance risk, and demonstrates platform maturity to funders and regulatory stakeholders who scrutinise volunteer credential management.
This story has a direct dependency on the pause story (story-peer-mentor-pause-reactivation-peer-mentor-001) and should be scheduled in the same sprint or immediately after to avoid integration gaps. Effort is similar to the pause story but adds one meaningful complexity: the certification expiry check and conditional warning flow. This requires integration with the certification data store and a configurable expiry threshold (currently 30 days). UAT must cover six acceptance criteria including offline reactivation, expired and near-expiry certification branches, and coordinator notification delivery.
Stakeholders to involve: volunteer programme managers at NHF and HLF should validate the 30-day warning threshold. Rollout risk is low if the pause story is stable, as the status toggle is a shared component. Key delivery risk is the certification expiry logic — ensure the threshold is a configurable setting rather than a hardcoded value to allow future adjustment without a code release.
Reactivation reuses the PATCH /mentor/status endpoint introduced in the pause story, with status transitioning from 'paused' back to 'active'. The primary new logic is the certification expiry check: on reactivation, the server must query the certifications table for the mentor's active certification and compare expiry_date against the current date plus a configurable warning window (default 30 days). If expired or within the warning window, the API response should include a certification_warning flag with expiry details. The client renders a persistent warning banner based on this flag and does not block reactivation — the mentor proceeds regardless.
A separate notification event must be dispatched to the coordinator for certification warnings, distinct from the reactivation notification, so coordinators can action them independently. Offline reactivation follows the same queue-and-replay pattern as pause. The certification check should be re-evaluated server-side when the queued event is processed, not at queue time, to ensure accuracy. Ensure the coordinator notification payload includes mentor name, chapter, and certification expiry date for actionable context.
Acceptance Criteria
- Given I am paused and logged in, when I view my profile or home screen, then a clear 'Reactivate' button or toggle is visible alongside a pause status banner
- Given I tap reactivate, when I confirm in the dialog, then my status changes to active immediately and the pause status banner disappears
- Given I have reactivated, when the status change is saved, then my coordinator receives an in-app and push notification confirming my return
- Given I reactivate and my certification is valid, when status is updated, then I appear in the active peer mentor list without further steps required
- Given I reactivate and my certification has expired or expires within 30 days, when the status update completes, then a certification expiry warning banner is displayed and the coordinator is also notified of the expiry
- Given I reactivate while offline, when connectivity is restored, then the reactivation is synchronised and the coordinator notification is delivered
Business Value
Frictionless reactivation is as important as an easy pause. If returning is cumbersome, mentors will delay or avoid coming back. A self-service reactivation path removes dependency on coordinator action, shortens the time a mentor is inactive, and directly improves volunteer retention metrics for NHF and HLF.
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 Activation Screen ui
- Certification Expiry Warning Banner ui
- Pause Status Indicator ui
- Pause Management Service service
- Certification Expiry Checker Service service
- Pause Notification Service service
- Peer Mentor Status Repository data
- Certification Status Repository data
- Pause Management Service service
- Peer Mentor Confirmation Banner ui
- Pause Notification Orchestrator service
- Pause Status Record Repository data
- Pause Status Webhook Handler infrastructure
- FCM Notification Dispatcher infrastructure