Service Layer medium complexity backend
1
Dependencies
1
Dependents
2
Entities
0
Integrations

Description

Business logic layer for managing organisation-level scenario configurations. Handles reading and writing JSON scenario rule definitions per chapter, validates rule structure, and enforces that only valid trigger types and metadata condition keys are used.

Feature: Scenario-based Follow-up Prompts

scenario-configuration-manager

Summaries

The Scenario Configuration Manager gives the organisation a controlled, validated way to manage which automated support prompts are active for each chapter — ensuring that only well-formed, authorised configurations are ever applied. By enforcing rule validation and providing sensible defaults for new chapters, it significantly reduces the risk of misconfiguration causing inappropriate or missing prompts. This protects the organisation's reputation with members, ensures consistent programme quality across chapters, and lowers the cost of onboarding new chapters by automating their initial setup. It also provides a single, auditable control point for prompt behaviour, which is valuable for compliance and programme governance reporting.

The Scenario Configuration Manager is a medium-complexity backend service that depends solely on scenario-rule-repository and sits upstream of both the configuration screen UI and the rule engine. It should be developed and unit-tested early in the sprint as it unblocks both dependent components. Key delivery considerations include agreeing the JSON rule schema with the team before implementing validateRuleDefinition(), since schema changes after the validator is built will require rework. Testing must cover validation rejection of invalid trigger types and unknown condition keys, default scenario provisioning for new chapters, and idempotent enable/disable toggle behaviour.

No external infrastructure dependencies exist beyond the repository layer.

ScenarioConfigurationManager is a backend service class that wraps scenario-rule-repository with validation and business logic. getChapterConfig() retrieves the full ChapterScenarioConfig record including all ScenarioRule entries and their enabled states. updateScenarioEnabled() writes the boolean toggle for a specific scenarioId within the chapter's config document, using an atomic field-level update on the repository. validateRuleDefinition() applies a schema check against an allowlist of valid triggerType enum values and permitted condition keys, returning a ValidationResult with error details on failure.

getDefaultScenarios() returns a hardcoded list of ScenarioRule objects used by resetToDefaults() to overwrite a chapter's config. All write operations should return typed result objects to allow callers to surface validation errors to the UI without throwing exceptions.

Responsibilities

  • Read chapter-specific scenario rule configurations
  • Write updated scenario enable/disable state per chapter
  • Validate scenario rule JSON against the rule schema
  • Provide default hardcoded scenario templates for new chapters

Interfaces

getChapterConfig(String chapterId): Future<ChapterScenarioConfig>
updateScenarioEnabled(String chapterId, String scenarioId, bool enabled): Future<void>
validateRuleDefinition(Map<String, dynamic> ruleJson): ValidationResult
getDefaultScenarios(): List<ScenarioRule>
resetToDefaults(String chapterId): Future<void>

Relationships

Dependencies (1)

Components this component depends on

Dependents (1)

Components that depend on this component

Related Data Entities (2)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/scenario-configurations 8 endpoints
GET /api/v1/scenario-configurations
GET /api/v1/scenario-configurations/:chapter_id
POST /api/v1/scenario-configurations
PUT /api/v1/scenario-configurations/:chapter_id
DELETE /api/v1/scenario-configurations/:chapter_id
PATCH /api/v1/scenario-configurations/:chapter_id/scenarios/:scenario_id
+2 more