# 1. Platform Branding

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

---

## 1. Platform Branding

### 1.1 Configure Platform Name and Logo
**What it does:** Sets the platform's identity: the display name shown across the interface and in communications, and the logo used in the web app, emails, and exported materials. Changes apply platform-wide and are previewable before saving, so the Super Administrator can confirm the branding looks correct everywhere it appears.

**Sub-features:**
- Platform display name (used in the interface, browser context, and communications)
- Logo upload with format/size validation and a preview
- Logo variants: full logo, compact/favicons-style mark, and a light/dark variant where applicable
- Preview of the branding across key surfaces (interface header, email header, export header)
- Save with immediate platform-wide application
- Change history of branding updates
- Audit logging of branding changes

**Super Administrator User Journey:**
1. The brand team finalizes the new logo. Super Admin opens System Settings → Platform Branding.
2. Updates the platform display name and uploads the new logo files (full logo and compact mark), each passing format/size validation.
3. Uses the preview to check the branding across surfaces: the interface header, an email template header, and a report export header all show the new name and logo correctly.
4. Confirms the light/dark variants render correctly (the logo is visible on both light and dark backgrounds).
5. Saves; the new branding applies platform-wide immediately.
6. Opens a few key screens and a test email to confirm the live rendering matches the preview.
7. Reviews the change history: the previous branding is recorded with the date and the acting admin.
8. The branding change is audit-logged with the assets changed and the timestamp.

**Rules & Edge Cases:**
- Logo uploads are validated (format, size, dimensions); invalid files are rejected with the specific reason.
- The preview covers the key surfaces before save, so a bad asset is caught before it goes live.
- Light/dark variants are required where the interface has both themes; a missing variant is flagged.
- Changes apply platform-wide on save; there is no per-institute branding in this setting (institute-level identity is separate).
- The previous branding is retained in the change history for rollback reference.
- Branding changes are audit-logged with the acting admin and timestamp.

### 1.2 Configure Email Templates and Branding
**What it does:** Controls the transactional and communication email templates: their content structure, the branded header/footer (logo, name, colors), and the per-template settings (subject, body blocks, links). Templates are used by all automated emails (verification, receipts, notifications), so branding and content are consistent across every email the platform sends.

**Sub-features:**
- Template library: all transactional/communication email templates with their trigger context
- Template editor: subject, body blocks, merge fields (user name, course, amount, etc.), and links
- Branded header and footer applied from the platform branding (logo, name, colors)
- Per-template settings: send enablement, subject line, and required blocks
- Preview with sample merge-field values before saving
- Language variants per supported language (see Localization)
- Audit logging of template changes

**Super Administrator User Journey:**
1. The team wants to update the welcome email's copy. Super Admin opens the template library and selects the "Welcome" template.
2. Edits the body blocks and subject, using the merge-field palette to insert the user's name and their first course.
3. Previews the template with sample values: the branded header (logo, name) renders, the merge fields show sample data, and the links are correct.
4. Checks the language variants: the English update is made; the other supported languages are flagged for translation (routed to the translation process).
5. Saves; the new template applies to all subsequent welcome emails.
6. Sends a test email to a test account to confirm the live rendering (header, body, links, unsubscribe/compliance footer).
7. For a compliance update (a required footer line), Super Admin updates the shared footer block once; it propagates to all templates that use it.
8. The template change is audit-logged with the template, the blocks changed, and the timestamp.

**Rules & Edge Cases:**
- The branded header/footer is driven by the platform branding; updating branding updates email branding without editing each template.
- Merge fields are validated: a template cannot reference a field that does not exist for its trigger context.
- The preview uses sample values, so the layout is checkable without sending a real email.
- Language variants are tracked per supported language; an untranslated variant is flagged, not silently sent in the wrong language.
- Compliance-required blocks (e.g., footer legal lines) are protected: they cannot be removed, only updated.
- Template changes are audit-logged; a test-send path exists to verify live rendering.