Coordinator Proxy Reporting

Description

This feature allows coordinators to register activities on behalf of peer mentors who are unable or unwilling to use the app themselves. The coordinator selects a peer mentor from their managed list, fills in the activity details, and submits the record as a proxy action. This ensures complete and accurate reporting even when individual peer mentors lack digital skills or access. The feature addresses a core operational reality: not all peer mentors will adopt the app at the same pace. Coordinators serve as a bridge, maintaining reporting continuity during the transition period and for users who permanently prefer paper or verbal reporting. The system clearly marks proxy-registered activities to distinguish them from self-registered ones.

User Flow

Click to expand

Analysis

Business Value

Organizations like NHF and HLF have peer mentors who will never independently use a mobile app due to age, cognitive limitations, or personal preference. Without proxy reporting, their activities go unrecorded, causing systematic underreporting that directly affects Bufdir funding calculations and organizational statistics. This feature preserves reporting completeness regardless of individual digital adoption levels. From a strategic perspective, proxy reporting removes the all-or-nothing adoption barrier. Organizations can onboard at their own pace without sacrificing data integrity. It also reduces coordinator friction by giving them a single tool for oversight and data entry, rather than juggling app-based and paper-based records simultaneously. This accelerates overall platform adoption across the organization.

Implementation Notes

Implementation requires coordinator-scoped access control that restricts proxy registration to peer mentors within the coordinator's assigned local association. The activity creation flow reuses the existing Simple Activity Logging components but injects a peer mentor selector step at the start, with the submitting user stored separately as the proxy author. The database schema must store both the activity owner (peer mentor) and the recorder (coordinator) as distinct fields. Flutter BLoC state management will handle the dual-identity context cleanly by passing a proxyForUserId parameter through the activity creation event chain. The UI should clearly display the proxy context at all times during entry to prevent accidental self-registration. API endpoints must validate coordinator-to-peer-mentor relationship server-side before accepting proxy submissions to enforce tenant and role boundaries.