Reminder Configuration Repository
Component Detail
Description
Data access layer for reading and writing organisation-specific reminder threshold settings from the org settings table. Provides typed access to reminder_days and escalation_days values with defaults fallback when no org-specific config exists.
reminder-config-repository
Summaries
This component gives programme administrators direct control over how aggressively the system follows up on inactive assignments, without requiring any engineering intervention. By storing reminder and escalation thresholds per organisation, each customer can tune the system to match their programme culture — some organisations may prefer gentle nudges after two weeks, others may require escalation within five days. This configurability is a direct competitive differentiator, enabling the platform to serve organisations with vastly different operational rhythms without custom development. It also reduces churn risk by ensuring the system behaves in line with each client's expectations, and eliminates the need for support escalations to adjust hardcoded values when organisational policies change.
Low-complexity component with a small, stable interface and a single table dependency on org settings. Development effort is one sprint or less for an experienced backend developer. The main coordination point is agreeing on the ReminderConfig schema — specifically the field names reminderDays and escalationDays and their validation constraints (e.g., minimum/maximum day ranges) — before both this component and the reminder scheduler service begin implementation. Default config behaviour must be defined with the product team: what thresholds apply when no org-specific row exists?
This decision affects both the getDefaultConfig() implementation and acceptance test cases. No external service dependencies means testing is straightforward with a local SQLite or test Postgres instance. Risk is low; the main delivery risk is schema changes late in the sprint caused by evolving product requirements around threshold ranges.
Simple CRUD data component scoped to the org_settings table, providing typed access to two configuration fields: reminderDays and escalationDays. getReminderConfig(orgId) should perform a SELECT with a LEFT JOIN or fallback to getDefaultConfig() when no row exists for the given orgId — avoid throwing on missing config as the caller (reminder scheduler) must always receive usable values. updateReminderConfig() should upsert rather than require a pre-existing row. Validation logic in this layer should enforce sane day ranges (e.g., 1–365) before write to prevent the scheduler from receiving zero or negative thresholds that would incorrectly flag all assignments.
The ReminderConfig interface is the shared contract between this repository and the scheduler service — define it in a shared types module to avoid duplication. This component has no caching requirements given low read frequency (once per scheduler run per org).
Responsibilities
- Read reminder threshold configuration for an organisation
- Read escalation threshold configuration for an organisation
- Write updated threshold values to org settings table
- Return default thresholds when org-specific config is absent
- Validate threshold values before persistence
Interfaces
getReminderConfig(orgId): ReminderConfig
updateReminderConfig(orgId, config: ReminderConfig)
getDefaultConfig(): ReminderConfig
ReminderConfig: {reminderDays: number, escalationDays: number}
Relationships
Dependents (3)
Components that depend on this component