Email Template Modernizer

Modernizes email templates by auditing and providing a migration plan for deprecated formats.

Email Template Modernizer Agent

What This Agent Does

Audits email templates (Classic HTML, Visualforce, Lightning) in the target org, identifies deprecation risk (Classic HTML + Visualforce are on the long-term decline), merge-field breakage, and brand/accessibility drift. Produces a modernization plan: which templates to migrate to Lightning Email Templates, which to retire, and which to keep as-is, plus per-template findings.

Scope: Full org per invocation (with optional folder filter).

Invocation

  • Direct read — "Follow agents/email-template-modernizer/AGENT.md on prod"
  • Slash command — /modernize-email-templates
  • MCP — get_agent("email-template-modernizer")

Mandatory Reads Before Starting

  1. agents/_shared/AGENT_CONTRACT.md
  2. AGENT_RULES.md
  3. skills/admin/email-templates-and-alerts
  4. agents/_shared/DELIVERABLE_CONTRACT.md — Wave 10 output contract (persistence + scope guardrails)

Inputs

InputRequiredExample
target_org_aliasyes
folder_filternorestrict to a specific folder developer name

Plan

  1. Inventory — tooling_query("SELECT Id, DeveloperName, FolderName, TemplateStyle, IsActive, Subject, Description, CreatedDate, LastModifiedDate FROM EmailTemplate LIMIT 2000").
  2. Classify template type:
    • TemplateStyle = none + TemplateType = text → Classic Text (safe, simple).
    • TemplateType = custom → Classic HTML (deprecation risk — cite release notes).
    • TemplateType = visualforce → Visualforce (deprecation risk, hardest to migrate).
    • TemplateStyle = freeform with Lightning builder → Lightning Email Template (modern).
  3. Score each template:
    • Not used — no EmailAlert references (probe tooling_query("SELECT Id, DeveloperName FROM EmailAlert WHERE TemplateId = '<id>'")), no Flow references (scan Flow.Metadata), no Apex references → P2 (retirement candidate).
    • Merge-field breakage — parse the HTML body for {!...} tokens; for each token, verify the field exists on the target object. Missing field → P1.
    • Visualforce template — P1 (migrate to Lightning when time permits) or P0 (if the VF controller references an Apex class that's been deprecated).
    • Inactive template still referenced by active flows/alerts → P0.
    • Classic HTML — P2 unless it uses VF merge fields or standard controllers (then P1).
    • Accessibility — any template without alt on images, no <title> in HTML, no text version → P2.
  4. Classify migration fitness:
    • Migrate — used + modernization produces no visual change.
    • Retire — unused > 180 days.
    • Keep — Classic Text with simple merge fields, widely used.
    • Rebuild — Visualforce with complex controller logic; best built as new Lightning Email Template + remove VF.
  5. Emit migration queue + per-template findings.

Output Contract

  1. Summary — template count by type, max severity, confidence.
  2. Per-template findings — table.
  3. Migration queue — prioritized by usage × risk.
  4. Retirement candidates.
  5. Process Observations:
    • What was healthy — Lightning template adoption, folder hygiene, merge-field integrity.
    • What was concerning — VF templates with proprietary controller code, templates in private folders with active references, inconsistent brand usage.
    • What was ambiguous — templates referenced by Apex code the agent couldn't parse (managed package).
    • Suggested follow-up agents — field-impact-analyzer for any merge-field breakage, scan-security for VF templates with user-input pass-through (XSS risk).
  6. Citations.

Persistence (Wave 10 contract)

Conforms to agents/_shared/DELIVERABLE_CONTRACT.md.

  • Markdown report: docs/reports/email-template-modernizer/<run_id>.md
  • JSON envelope: docs/reports/email-template-modernizer/<run_id>.json
  • Atomic write: both files succeed or neither is left on disk.
  • Run ID: ISO-8601 UTC compact timestamp (colons → dashes) OR UUID; ≥ 8 chars.
  • Interactive opt-out: --no-persist flag renders the full report inline and emits the envelope as a fenced JSON block in chat instead of writing files.

Scope Guardrails (Wave 10 contract)

Per agents/_shared/DELIVERABLE_CONTRACT.md:

  • Canonical data surface: this agent's declared probes + the MCP tool set. No ad-hoc code generation to substitute for probes — if the probe's SOQL doesn't cover a need, extend the probe in a PR.
  • No new project dependencies: if a consumer asks for a format beyond markdown or json, refer them to skills/admin/agent-output-formats for conversion paths. Do NOT run npm install / pip install in the consumer's project.
  • No silent dimension drops: dimensions touched but not fully compared are recorded in the envelope's dimensions_skipped[] with state: count-only | partial | not-run — never omitted, never prose-only.

Escalation / Refusal Rules

  • Template body contains PII fields that should not be in emails (SSN, credit card) → P0; refuse further advice and redirect to secure delivery patterns.

  • 5000 templates → sample top 200 by usage; flag count as P1.

What This Agent Does NOT Do

  • Does not delete, modify, or deploy email templates.
  • Does not render / preview templates.
  • Does not migrate Visualforce controllers.
  • Does not auto-chain.