Functional Story 13: Configure Hierarchical System Parameters
1. Business Purpose
Administrators need to configure system behavior without requesting a deployment every time a tenant, system, or module requires a different operational rule. UMS must allow controlled configuration at multiple scopes while preserving clear inheritance and override behavior.
2. Actors
| Actor | Responsibility |
| :— | :— |
| Global Administrator | Defines defaults that apply platform-wide. |
| Tenant Administrator | Adjusts behavior for a tenant when allowed by global policy. |
| System Administrator | Adjusts behavior for a specific registered system or suite. |
| Client System | Consumes the effective configuration resolved by UMS.
3. Business Preconditions
- The administrator is authenticated.
- The administrator has permission to manage configuration for the selected scope.
- The target tenant, system, or module is registered and active.
4. Main Functional Flow
- The administrator opens the configuration panel.
- The administrator selects the scope where the setting will apply: Global, Tenant, System/Suite, or Module.
- The administrator enters a parameter identifier, value, and a clear description of its business purpose.
- The administrator decides whether lower scopes may override the value.
- The system checks whether a higher-level restriction prevents the requested change.
- The system saves the parameter and makes it available for effective configuration resolution.
- Client systems receive the most specific applicable value according to the hierarchy.
5. Alternative Flows and Exceptions
A. Override Not Allowed
If a higher-level administrator marked a parameter as non-overridable, the system prevents the lower-level change and explains which higher-level rule is controlling the behavior.
B. Missing Functional Description
If the administrator does not provide a meaningful description, the system prevents publication and asks for a description that explains purpose, impact, expected behavior, and applicable scope.
C. Duplicate Parameter in the Same Scope
If a parameter with the same identifier already exists in the selected scope, the system prevents duplication and guides the administrator to edit the existing parameter or create a versioned change.
6. Business Rules
- The most specific applicable value wins: Module over System/Suite, System/Suite over Tenant, Tenant over Global.
- A non-overridable value blocks changes in lower scopes.
- Every configurable parameter must include
code, value, and description.
- The description must explain purpose, functional impact, expected behavior, and scope.
- Sensitive values must be treated as protected configuration and must not be exposed in plain text to unauthorized users.
7. Acceptance Criteria
- An administrator can create a parameter at an allowed scope.
- The system prevents lower-scope overrides when a higher-scope rule disallows them.
- The effective value returned to a client system matches the hierarchy rules.
- A parameter cannot be published without a clear business description.
- Duplicate parameter identifiers are not allowed within the same scope.
8. Technical Requirements
[!WARNING]
ESTADO DE IMPLEMENTACIÓN: DIFERIDO / FUERA DE ALCANCE
En la fase actual, la gestión activa de parámetros jerárquicos de configuración (AppConfiguration) está diferida y no está implementada dentro del proyecto principal de dominio de C#.
- Enforce scope-aware configuration parameters structure.
- Support audit tracking on configuration overrides.
9. Traceability
- Entities:
AppConfiguration (Deferred AR)
- ADRs: ADR-0024, ADR-0047
- Technical Enabler: TE-02 Resolve Hierarchical System Configuration
- Standard: Functional Story Writing Standard; Parametric Catalog Standard