# 3. Feature Toggles

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 3. Feature Toggles

### 3.1 Enable or Disable Platform Features System-Wide
**What it does:** Controls the availability of platform features at the system level: the Super Administrator can enable or disable a feature for the whole platform, turning capabilities on or off without a release. Toggles are the operational lever for launching features gradually, disabling a problematic feature quickly, and aligning the platform's surface with the current operating model.

**Sub-features:**
- Feature toggle catalog: all toggleable features with their current state
- System-wide enable/disable per feature
- Immediate effect: a disabled feature is unavailable platform-wide on the next request
- Dependency awareness: toggles that depend on other features show the dependency state
- Change preview: what a toggle change affects (surfaces, user counts where relevant)
- Change history of toggle states
- Audit logging of toggle changes with the acting admin

**Super Administrator User Journey:**
1. A new feature is being rolled out gradually. Super Admin opens the Feature Toggles catalog and confirms the feature is currently disabled system-wide.
2. Reviews the change preview for enabling it: the surfaces it appears on and the user impact.
3. Enables the feature; it becomes available platform-wide on the next request.
4. Monitors the feature's health (via System Health & Performance Monitoring) for the first period.
5. If an issue appears, Super Admin disables the feature from the same catalog; it is unavailable platform-wide immediately, containing the issue.
6. Reviews the dependency view: a feature that depends on another shows whether its dependency is enabled, so a toggle does not produce a broken state.
7. Checks the change history: each toggle change shows the previous and new state, the acting admin, and the timestamp.
8. The toggle change is audit-logged, so the feature's availability over time is reconstructable.

**Rules & Edge Cases:**
- A toggle change takes effect on the next request; there is no stale-availability window.
- Dependencies are surfaced: enabling a feature whose dependency is disabled is flagged (not silently allowed into a broken state).
- The change preview shows the impact before the change, so toggles are deliberate.
- Toggling off a feature in active use ends its availability on the next request; in-progress work is handled per the feature's rules.
- The change history records every state change for reconstruction.
- Toggle changes are audit-logged with the acting admin and timestamp.

### 3.2 Control Availability of Optional Features
**What it does:** Manages the optional/secondary features of the platform — capabilities like live sessions and social learning that are not core to every use — with availability controls that go beyond a simple on/off: enabling them, scoping their availability, and coordinating their launch with the supporting configuration (permissions, content, and operations) they need.

**Sub-features:**
- Optional feature catalog (live sessions, social learning, and similar secondary capabilities)
- Enable/disable per optional feature
- Availability coordination: the supporting configuration (permissions, content, operational readiness) checked before enablement
- Launch checklist: the items that must be in place before an optional feature is turned on
- Post-enable monitoring: health and usage signals after launch
- Disable path with user communication for a pulled feature
- Audit logging of optional-feature availability changes

**Super Administrator User Journey:**
1. The team is ready to launch live sessions. Super Admin opens the optional feature catalog and selects "Live sessions".
2. Reviews the launch checklist: the supporting permissions are defined (who can host, who can join), the scheduling surface is configured, and the operational readiness (support briefed) is confirmed.
3. Completes any outstanding checklist items (assigns the host permission to the relevant roles via Role & Permission Management).
4. Enables the feature; it becomes available to the users whose roles permit it.
5. Monitors the post-enable signals: usage, session health, and any errors via the monitoring module.
6. For a feature that needs to be pulled (a social-learning issue), Super Admin disables it and triggers the user communication: the feature is temporarily unavailable, with the expected restoration.
7. Reviews the availability change history: each optional feature's on/off timeline with the acting admin and timestamp.
8. The availability change is audit-logged, and the launch checklist completion is recorded with the enablement.

**Rules & Edge Cases:**
- Optional features are gated by both the toggle and the user's permissions: a feature is available only where the toggle is on and the role permits it.
- The launch checklist must be complete before enablement; an incomplete checklist blocks the toggle with the missing items shown.
- Disabling an optional feature in active use ends availability on the next request and triggers user communication.
- Post-enable monitoring is expected: a launched feature is watched, not just switched on.
- The availability timeline is reconstructable from the change history.
- Optional-feature availability changes are audit-logged with the acting admin and timestamp.