Classic Email Templates
A Classic Email Template is the original Salesforce email template format, built and edited in Setup under Classic Email Templates.
Definition
A Classic Email Template is the original Salesforce email template format, built and edited in Setup under Classic Email Templates. It comes in four types: Text, HTML (using Classic Letterhead), Custom, and Visualforce. Each one stores reusable email content with merge fields, so the platform fills in record values like a contact name or case number when the email is sent.
This format predates Lightning Email Templates, which is why the site tags it as legacy. It still works in Lightning Experience and remains common because automation such as workflow Email Alerts and approval-process actions points at these templates. Most new authoring now happens in Lightning Email Templates, but Classic templates persist wherever older automation already references them.
The four Classic template types and where they still fit
Text templates
A Text template is plain text with no HTML and no styling. Salesforce describes it as simple text format that does not support design elements. Any user can create one, which makes it the lowest-friction option for teams that just need the words to go out. It renders the same way in every email client because there is nothing for a client to misinterpret. That reliability is the whole point. Use Text templates for transactional confirmations, internal notifications, and compliance-sensitive messages where the content matters and the look does not. Merge fields still work, so you can personalize the greeting and pull in record details. What you give up is branding: no logo, no colors, no layout. If a stakeholder later insists on a branded version, you usually rebuild the message as an HTML or Custom template rather than retrofitting the text one. For high-volume system mail, Text templates also sidestep the cross-client rendering testing that HTML formats demand, which keeps maintenance low.
HTML (using Classic Letterhead)
This type pairs an HTML body with a Classic Letterhead, the legacy branded wrapper that supplies a header and footer. The template inherits the logo, colors, and text settings defined on the Letterhead, and you fill the middle with your content. Salesforce restricts creating and editing these to administrators and users with the Edit HTML Templates permission, so it is not a self-serve format for every rep. The Letterhead model gives you consistent branding across many templates from one source, which is handy when a company rebrands and wants every email to follow. The trade-off is rigidity. The header and footer come from the Letterhead, so anything outside that frame is fixed. Classic Letterheads are a Classic-only feature; the modern path is a Lightning email template combined with Enhanced Letterheads or Email Branding. If your org is moving authoring to Lightning, this is one of the types that needs a rebuild because the Letterhead concept does not carry over directly.
Custom HTML templates
A Custom template is HTML without a Classic Letterhead. The author writes the full markup, which gives the most layout freedom of the standard types. Salesforce labels this option Custom (without using Classic Letterhead), and like the Letterhead type it requires the Edit HTML Templates permission. Choose Custom when the Letterhead frame is too restrictive: detailed marketing layouts, custom-branded transactional mail, or designs that need full control over structure and CSS. The freedom comes with responsibility. Because you own the entire HTML, you also own how it renders across clients, and email clients are notoriously inconsistent. A layout that looks correct in the Salesforce preview can break in Outlook, which uses a different rendering engine than browsers do. Inline styles, table-based layouts, and conservative CSS tend to survive better than modern flexbox or grid. Always send test copies to real inboxes before you wire the template into automation, because a broken Custom template multiplies across every email the automation sends.
Visualforce templates
A Visualforce template renders through a Visualforce page, so it can do things the other three types cannot. Administrators and developers build these, and they support advanced merging where one email pulls data from multiple related records. The messaging:emailTemplate component wraps the page, with recipientType and relatedToType attributes setting the context. Inside, apex:repeat loops over related lists, so you can render every case on an account, every line item on an order, or any collection the data model exposes. A custom Apex controller can extend that further with computed values and conditional content. This is the format to reach for when standard merge fields fall short, for example when you need a table of related records or logic that decides what to show. The cost is complexity: Visualforce templates need development skills, version control discipline, and testing, and they are tied to the Visualforce framework. For most everyday emails they are overkill, but for data-rich automated messages they remain the most capable Classic option.
Merge fields use the Salesforce Merge Language
Classic Email Templates use the Salesforce Merge Language, written as {!Object.Field}, for example {!Contact.FirstName} or {!Case.CaseNumber}. The platform resolves each merge field when the template is inserted, based on the Recipient and the Related To record. This timing matters: if you change the Recipient or Related To values after inserting the template, the email content does not update to match. That is a common source of confusion when reps edit a draft. The Classic syntax is different from Lightning email templates, which use the Handlebars-style {{{Account.Field}}} format introduced in Summer 18. Standard Classic types reach fields on the primary record and related records one level away through lookup relationships. Cross-object references beyond what the relationship supports do not resolve and quietly produce blank values. Visualforce templates escape this limit because the underlying page can query whatever the controller allows. Whenever you build or edit a template, test it against a real record so a mistyped field name surfaces as a blank in your test send rather than in a customer email.
How automation references Classic templates
The reason Classic Email Templates have not faded away is automation. Workflow Email Alerts and approval-process Email Alerts select a template, and those Email Alerts still run inside Process Automation even after Salesforce steered new work toward Flow. Flow can also send email: the Send Email action lets you compose content inline or reference an existing template, and it accepts both Classic and Lightning templates. Salesforce notes that using a template in the Send Email action changes which API the action calls, which moves the send against the General Email Limit instead of the Daily Workflow Email Limit. Automation references a template by its identifier, so editing the template body updates every alert and action that points at it without any rewiring. That is powerful and also a trap. Renaming or deleting a referenced template can break the automation, sometimes silently, so audit references before you change anything. When you migrate a workflow rule to Flow, the existing Email Alert can carry over, which is one way teams keep Classic templates alive while modernizing the surrounding logic.
Migrating toward Lightning Email Templates
Lightning Email Templates are the current direction. They add a richer authoring experience, sharing with other users through folders, and inline images, and you can use Classic templates inside Lightning Experience while you transition. The catch is that templates created in Lightning cannot be used back in Salesforce Classic, so the move is one-way. Migration is not a button. You recreate each Classic template as a Lightning template, translate the merge syntax from {!Object.Field} to the Handlebars format, rebuild any Letterhead branding as Enhanced Letterheads or Email Branding, and repoint automation that referenced the old template. Visualforce templates are the hardest to move because their logic has no direct Lightning equivalent. Some teams keep specific Classic templates indefinitely precisely because an Email Alert or legacy integration still depends on them, and rebuilding is not worth the risk. A practical approach is to inventory both Classic and Lightning templates, map which automation uses what, then migrate in waves rather than all at once so nothing breaks unnoticed.
How to create a Classic Email Template
Classic Email Templates are created in Setup, not in the Lightning email composer. The flow below covers the standard path. The exact fields you fill depend on which of the four types you choose at the start.
- Open Classic Email Templates in Setup
In Setup, search for Classic Email Templates (in Salesforce Classic the path is Setup, Communication Templates, Email Templates). Click New Template to begin. Folder access and the Edit HTML Templates permission govern who can create HTML and Custom types.
- Choose the template type
Pick Text, HTML (using Classic Letterhead), Custom (without using Classic Letterhead), or Visualforce. If you choose the Letterhead type, select an existing Classic Letterhead so the header and footer are ready before you add content.
- Set properties and write the content
Give the template a name, a unique name (developer name), an encoding, and a subject. Mark it Available For Use so it appears in pickers. Write the body and insert merge fields with the {!Object.Field} syntax for any record values you want personalized.
- Preview, save, and test
Save the template, then use the preview or send a test email against a real record. Confirm every merge field resolves and, for HTML and Custom types, that the layout holds up in Outlook and a webmail client before any automation uses it.
The display label shown when users pick a template in the composer or in automation.
The developer (API) name that automation and code use to reference the template; renaming the display name does not change this.
The character set for the template body, for example Unicode (UTF-8), which controls how text is rendered.
The email subject line, which can include merge fields just like the body.
The checkbox that makes the template selectable; clear it and the template stays hidden from pickers.
- Merge fields resolve when the template is inserted, based on the Recipient and Related To values; changing those afterward does not update the inserted content.
- Creating or editing HTML and Custom templates requires the Edit HTML Templates permission, so not every user can build them.
- Renaming or deleting a template that an Email Alert references can break automation, sometimes without an obvious error; audit references first.
- Classic Letterheads do not carry into Lightning; rebuild branding as Enhanced Letterheads or Email Branding when you migrate.
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Classic Email Templates.
Hands-on resources to go deeper on Classic Email Templates.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Can a Salesforce admin configure Classic Email Templates without writing code?
Q2. Why is understanding Classic Email Templates important for Salesforce admins?
Q3. In which area of Salesforce would you typically find Classic Email Templates?
Discussion
Loading discussion…