Configure Duplicate Detection Sensitivity Thresholds
Different chapters have different activity patterns. A chapter running daily drop-in sessions may legitimately register multiple activities for the same peer mentor on the same day, while another chapter where each peer mentor meets each contact only once per week should flag any same-day duplicate. The coordinator should be able to configure the detection window (e.g., same day, within 4 hours, exact time overlap) and optionally exclude specific activity types from duplicate checks.
User Story
Audience Summaries
Configurable duplicate detection thresholds directly protect the organization's credibility and funding integrity with Bufdir. Chapters with high-frequency activity patterns — such as daily drop-in sessions — generate legitimate same-day registrations that a rigid detection rule would flag as errors, eroding coordinator trust in the tool. Conversely, chapters with structured weekly schedules need tight controls to catch genuine data entry mistakes. By allowing coordinators to tune detection windows and exclude specific activity types, the platform adapts to each chapter's operational reality.
This prevents the 'cry wolf' failure mode where over-sensitive warnings are routinely dismissed, which is the most dangerous state a compliance system can reach. Sustained coordinator trust in warning systems is a measurable retention and satisfaction driver, and accurate reporting protects grant revenue directly.
This story has moderate-to-high delivery complexity because it introduces a per-chapter configuration layer that must propagate correctly across all coordinators within the same chapter in real time. Key acceptance criteria — specifically that a configuration change by one coordinator applies to submissions from other coordinators in the same chapter — introduces a shared-state concern that must be explicitly designed and tested. The dependency on story-duplicate-activity-detection-coordinator-1 means this story cannot be started until the base duplicate detection feature is complete and stable. Stakeholders include chapter coordinators and system administrators.
UAT should include multi-user scenarios where one coordinator changes thresholds and another submits immediately after. Rollout risk is low if defaults are sensible ('within same day', all types included), as new users will experience a reasonable baseline without any configuration action.
Implementation requires a chapter-scoped configuration table storing at minimum: threshold_type (enum: exact_overlap, within_hour, within_day), and a set of excluded activity type IDs. The duplicate detection logic — introduced in the dependent story — must be refactored to accept a configuration context object rather than using hardcoded constants. A settings UI screen is needed with radio/select inputs for threshold and toggle inputs per activity type. On save, the config must be persisted and a cache or reactive store updated so that in-flight submission checks on other sessions in the same chapter use the latest value.
Edge cases: what happens if the config is changed while a submission wizard is open? Recommend reading config at submission-check time, not at wizard-open time. Default seeding is required for new chapters on first login. All acceptance criteria map to integration-level tests covering configuration persistence and cross-coordinator propagation.
Acceptance Criteria
- Given the coordinator accesses duplicate detection settings, When they view the configuration screen, Then they can set the time-overlap threshold: 'exact time overlap', 'within same hour', 'within same day'
- Given the coordinator sets a threshold, When a new activity is submitted, Then duplicate detection uses the configured window to determine if a match exists
- Given the coordinator wishes to exclude an activity type from duplicate detection (e.g., 'group informational session'), When they toggle that type off in settings, Then submissions of that activity type bypass duplicate checks
- Given the coordinator saves a configuration change, When another coordinator in the same chapter submits an activity, Then the new threshold applies to their submission as well
- Given default settings are in place, When a new coordinator logs in for the first time, Then the default threshold is 'within same day' with all activity types included
Business Value
A one-size-fits-all duplicate detection rule will either miss real duplicates for strict operational chapters or generate so many false positives for high-frequency chapters that coordinators learn to dismiss warnings reflexively. Configurable thresholds ensure the detection system remains actionable rather than becoming noise, which is critical to sustaining coordinator trust in the tool over time.
Components
- Duplicate Detection Service service
- Duplicate Activity Detection Service service
- Duplicate Check Repository data
- Duplicate Activity Detector infrastructure