Email Template
An Email Template is a reusable, predefined layout for an outgoing email in Salesforce.
Definition
An Email Template is a reusable, predefined layout for an outgoing email in Salesforce. It stores the subject line, the body content, merge fields that pull in record data, and any styling or attachments. Because the content is saved once and referenced everywhere, the same template can drive a manual send from a record page, an automated Email Alert, a Flow Send Email action, or an Approval Process notification. Update the template in one place and every send that uses it reflects the change.
Salesforce platform email supports a few template types. Classic Email Templates are the original format and come in four flavors: Text, Custom HTML, HTML with Letterhead, and Visualforce. Lightning Email Templates arrived with Lightning Experience and use a modern drag-and-drop builder. Visualforce Email Templates are built in code for content that needs conditional logic or repeating data. One rule worth memorizing: Lightning templates cannot be used in Salesforce Classic, though Classic templates do work in Lightning Experience.
How email templates fit together in a Salesforce org
The template types and how they differ
Salesforce platform email gives you several template types, and the right pick depends on complexity and what already exists in your org. Classic Email Templates are the oldest format. They split into four kinds: plain Text, Custom HTML where you paste your own markup, HTML with Letterhead which wraps content in a branded header and footer, and Visualforce for code-driven output. Lightning Email Templates came with Lightning Experience and run on a visual builder with rich formatting and an easy merge-field picker, so most admins now default to them for new work. Visualforce Email Templates are written in markup and Apex, which lets them loop over child records, apply conditional logic, and render attachments that the visual editors cannot produce. All of these can coexist in the same org. The one hard limit to remember is direction: a Lightning template will not open in Salesforce Classic, while Classic templates (Text, Custom HTML, Letterhead, and Visualforce) remain usable inside Lightning Experience. That asymmetry shapes migration plans for orgs still running both interfaces.
Merge fields and two different syntaxes
A template becomes personalized through merge fields, which are placeholders that resolve to record data when the email is generated. The detail many people miss is that Salesforce uses two merge languages depending on the template type. Classic and Visualforce templates use Salesforce Merge Language (SML), written with a single curly brace and a bang, like {!Contact.FirstName} or {!Opportunity.Amount}. Lightning Email Templates use Handlebars Merge Language (HML), written with triple curly braces, like the contact first name wrapped in three braces. The two are not interchangeable, so copying a body between template types without adjusting the syntax produces broken output. Nearly all standard and custom fields are available, and the Lightning builder includes a merge-field button that opens a picker so you do not have to type field names by hand. Custom fields follow the same pattern with their API names. The fields you can reference depend on the object the template is tied to, which is set through the Related To value covered next.
Related To: global versus object-specific templates
Lightning Email Templates carry a Related To field that controls where the template can be used and which merge fields are available. When Related To is blank, or set to Lead or Contact, the template is global and can be selected from almost any record. When Related To points at a specific object such as Account, Opportunity, Case, or a custom object, the template is scoped to that object and only appears when you are working from a matching record. This scoping is a feature, not a limitation. It keeps the template picker relevant, so an agent on a Case is not wading through fifty Opportunity templates. It also determines the merge-field set, because a template tied to Opportunity can reference Opportunity fields and its related parents. Plan this early. Teams often create a small set of global templates for common messages and then object-specific templates for the workflows that need particular fields. Getting Related To wrong is a frequent reason a template does not show up where someone expects it.
Folders, enhanced sharing, and access
Email templates live in folders, and folders decide who can see, use, and edit each template. With enhanced folder sharing enabled, you grant access by user, role, role and subordinates, or public group, and you choose between view access and edit access. Most orgs organize folders by team (Sales, Service, Marketing) or by purpose (Welcome, Renewal, Escalation), which keeps the picker manageable as the count grows. Folder hygiene stops mattering quietly and starts mattering loudly once an org passes a hundred templates, because a flat, unshared pile becomes impossible to navigate. There is a separate setting to turn on Folders and Enhanced Sharing for Email Templates, and enabling it changes how existing templates are organized, so read the considerations before flipping it in production. Public Read or Public Read/Write folders make templates broadly available, while restricted folders keep sensitive or regulated content in the hands of a specific group. Treat folders as the access-control layer for your template library, not just cosmetic grouping.
Visualforce templates for complex, code-driven email
When a message needs more than a visual editor can express, Visualforce Email Templates step in. They are defined with the messaging:emailTemplate component, which takes recipientType and relatedToType attributes to declare who receives the email and which object supplies the data. Inside it you place a messaging:htmlEmailBody for rich content or a messaging:plainTextEmailBody for text, and you can drop in standard Visualforce markup to loop over child records or branch on field values. The advantage over a static HTML template is the ability to perform advanced operations on the data sent to the recipient, like building a line-item table from an Opportunity's products. Attachments are handled with the messaging:attachment tag, and setting renderAs to PDF turns markup into a generated PDF document delivered with the email. A worked example: a quote email that lists every OpportunityLineItem in a table and attaches a PDF rendering of the same quote is straightforward in Visualforce but impossible in a plain Custom HTML template. These templates require developer effort, so reserve them for genuinely dynamic content.
Driving automation: alerts, Flow, and auto-response
Templates rarely act alone. The common pattern pairs a template with automation that decides when to send. An Email Alert references a template and a recipient set, and it fires from a Flow, a record-triggered process, or an Approval Process step. In Flow Builder, the Send Email action can reuse content from both Lightning and Classic email templates, so you are not rewriting the body inside the flow. Approval Processes attach templates to submission, approval, and rejection notifications. On the service side, Email-to-Case auto-response rules send a template-based acknowledgement the moment an inbound email creates a Case, giving the customer an immediate confirmation while the Case routes to an agent. Keep one distinction clear: the template is the content, the Email Alert or action is the trigger, and the actual sent record is an EmailMessage. Mixing these up leads to confusion when someone asks why an email went out. Build the template first, confirm its merge fields render, then wire it into whichever automation needs it.
Create a Lightning Email Template
Here is how to create a Lightning Email Template in Lightning Experience. You build it once in the Email Templates list, set who and what it relates to, then reference it from sends and automation.
- Open the Email Templates list
From the App Launcher, search for and open Email Templates. This is the Lightning home for templates. Click New Email Template to start a fresh one.
- Name it and set Related To
Give the template a clear, searchable name and choose a folder. Set Related To to a specific object for scoped templates, or leave it blank (or pick Lead or Contact) for a global template usable from most records.
- Write the subject and body with merge fields
Compose the subject and body in the builder. Use the merge-field button to insert HML placeholders so the email pulls live data. Add any static or dynamically generated attachments.
- Save, share, and wire it up
Save the template, then confirm its folder sharing grants the right teams access. Reference it from a manual send, an Email Alert, a Flow Send Email action, or an Approval Process notification.
A human-readable name shown in the template picker. Make it descriptive so the right people find it fast.
The folder the template is saved in. Folder sharing controls who can use and edit it, so pick one that matches the intended audience.
The email subject line. It can contain merge fields and is required for the template to send a usable message.
- Lightning templates use HML (triple curly braces) while Classic and Visualforce use SML ({!Field}); pasting a body across types breaks the merge fields.
- A Lightning template scoped with Related To set to a specific object will not appear on records of other objects, which surprises people expecting it everywhere.
- Lightning Email Templates cannot be opened or used in Salesforce Classic, so verify the interface your senders are on before standardizing on them.
- Salesforce does not keep native version history for templates, so an edit overwrites the prior content with no undo beyond deployment-level source control.
Prefer this walkthrough as its own page? How to Email Template in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on Email Template.
Hands-on resources to go deeper on Email Template.
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. Which three template types does Salesforce platform email support?
Q2. What does merge-field syntax like {!Contact.FirstName} do when a template renders?
Q3. How do most orgs control who can use and edit a given Email Template?
Discussion
Loading discussion…