Activity Flagging
Feature Detail
Description
This feature provides coordinators and administrators with a lightweight mechanism to mark suspicious, duplicate, or non-compliant activity registrations for follow-up without immediately rejecting them. A flagged activity remains in the system but is excluded from Bufdir report counts and reimbursement queues until the flag is resolved. The feature addresses the NHF-specific requirement for duplicate detection when multiple coordinators may register the same group event, and serves as a general-purpose quality control tool across all organizations on the platform.
User Flow
Analysis
Organizations like NHF operate across 1,400 local associations and 9 regions, making duplicate registrations of the same event a realistic and recurring problem that can inflate Bufdir reports and trigger incorrect reimbursements. A dedicated flagging mechanism — separate from outright rejection — gives coordinators a collaborative tool to investigate ambiguous cases without data loss. From a compliance perspective, being able to demonstrate that flagged records were reviewed and resolved provides an audit trail that satisfies grant accountability requirements. For organizations with high activity volumes, the ability to triage rather than binary approve/reject reduces the cognitive overhead of the review workflow.
Flagging state is stored as an additional status field on the activities table (e.g., status='flagged') with a separate flag_reason text column and flagged_by foreign key to users. The admin portal exposes a flag management component that lists all flagged activities with reason, flagger identity, and age of flag. Resolution actions (accept-as-is, correct-and-approve, reject) are gated by coordinator or org admin role. Automated duplicate detection runs as a background job on activity insert, comparing contact_id, date, and activity_type within the same local association within a configurable time window; suspected duplicates are auto-flagged with reason='suspected_duplicate'. All flag create/resolve events are written to audit_logs.
Components (113)
Shared Components
These components are reused across multiple features
User Interface (12)
Service Layer (34)
Data Layer (22)
Infrastructure (38)
User Stories
No user stories have been generated for this feature yet.