Deduplicate Participants Across Chapters Before Submission
Organisations like NHF have members affiliated with up to five local chapters, meaning a single peer-mentoring recipient could be counted multiple times across chapter-level activity reports. The deduplication service must resolve these duplicates using identity attributes before computing final participant totals. The coordinator should see a summary of how many duplicates were detected and merged so they can validate the outcome.
User Story
Acceptance Criteria
- Given activity records contain participants registered under multiple chapters, when aggregation runs, then the deduplication service identifies records belonging to the same individual
- Given duplicates are identified, when they are merged, then only one unique participant record is counted in the final Bufdir totals
- Given deduplication completes, when the aggregation summary is shown, then the number of detected duplicates and the resulting unique participant count are both visible
- Given no duplicates exist, when deduplication runs, then the participant count remains unchanged and no warning is displayed
- Given the coordinator reviews the deduplication report, when they see an unexpected duplicate, then they can drill down to see which chapters contributed the duplicate entries
Business Value
Inflated participant counts in Bufdir submissions constitute inaccurate reporting and can lead to audit findings, repayment demands, or reputational damage. Automatic deduplication ensures legal compliance, maintains the organisation's credibility with Bufdir, and removes a tedious manual reconciliation step that coordinators currently perform in spreadsheets.
Components
- Participant Deduplication Service service
- Bufdir Aggregation Service service
- Aggregation Query Builder data
- Multi-Organization Data Isolator data
- Supabase Aggregation RPC Functions infrastructure
- Bufdir Metrics Repository data
- Aggregation Summary Widget ui