Scalable, Efficient, Custom HTML Template Systems in Salesforce Marketing Cloud’s Content Builder
Jake Gibbs | April 17, 2020
Salesforce Marketing Cloud (SFMC) provides the framework to
support efficient, scalable, custom templates, thus allowing
non-technical users the option to easily build emails using a large library of custom-designed,
hand-coded modules without knowing a lick of html.
But since your account is only provisioned with “stock” or standard
SFMC template layouts that aren’t branded or very flexible, some work is
required to build your own custom template system to be fully branded, custom
coded, and ready for non-techies like marketers or designers to build emails.
What does the full process look like? Read on brave template builder!
What are the
benefits of modular template systems?
First, let’s clarify why modular design and a template
system is better than simply building a template or two and calling it good. A
template is typically seen as a rigid, unyielding layout that forces the
user to stick closely or exactly to that layout. While good for keeping consistency,
do you really want every email to look the same? And what if your content
deviates slightly or even majorly from the initial, rigid layout? What then?
You’ll have to build more templates to accommodate, which kind
of defeats the point of templates as you end up with “template bloat” as your
template count rises. Not only, then, does it become harder to figure out what
template goes with what scenario, but it also requires technical help to build new
templates each time an unforeseen scenario or layout is needed. Not ideal!
A better method is to think modularly. A module is a section
of an email template, not a template as a whole. A module could be a header, a
hero, an alert bar, a 2 column product section, an article, a footer, etc.
Modules can be rearranged, removed, or added as needed, creating highly
scalable and flexible layouts. The ideal template, then, would allow for
flexibility in how many modules and what order they go in. In other words, a
template system turns the template into a lego mat, while the modules are the
legos sitting in a container, ready to pull in as needed.
Modules allow you to build many layouts, create variations
of modules based on designs and content, and can be stored neatly away in an
organized content library folder structure. Ready to be pulled in at a moment’s
notice, this module library allows you to build many types of emails with one
single, master template. Down the road, you can easily expand your module
library and any new module will work with the master template without requiring
new templates to be built.
What does an
efficient process of planning and implementing a custom template system look
There are typically multiple
stages with multiple teammates, depending on your business structure and
workflow. They are as follows:
Strategy >> Marketers define the
use cases for emails in general. What emails do you need to achieve your
marketing goals? Are they for triggers, journeys, ad hoc campaigns, etc? What
should the emails achieve? Who will be building them? This bird’s eye view should
create a mind map of the requirements for what emails the template system
Content >> Now that the emails have
been defined, what content will be in these emails? What layouts are needed to
support that content? This stage requires thoughtful, module by module
wireframing and determining what content, how much content, and what variations
are needed. This stage should produce a list of every module needed, along with
wireframes for each module.
Design >> Once the content has been
well defined, it’s time to bring some life into these wireframes. Skilled
designers take these rough concepts of modules and ensure that their designs are
branded, appropriately eye-catching, user friendly, hierarchal, and are
possible to be coded given the many limitations of html for mobile, Dark Mode, stubborn
email clients like Outlook, etc. The designs should also be easy for a
non-technical user to edit, meaning fancy slice layouts, background images, etc
should be avoided to prevent difficulty in building the emails down the road.
In the end, the designs should be appealing, but not complicated as this will
pose problems for developers coding the modules and / or non-techies building
Coding and testing >> Here
developers take 100% approved, completed designs and work their magic. They
code a master template and modules in a way that they work seamlessly together.
Considering all major mobile and desktop clients such as iPhone, Android,
Outlook, Gmail, Yahoo, and many others, they platform test on Litmus or Email
on Acid to ensure the code renders flawlessly. In situations where email
clients don’t support advanced css properties (like rounded corners, custom
fonts, or drop shadows), they ensure graceful fallbacks. Once their part is
completed, no coding will be needed by anyone building emails from these
Platform Implementation >> After
the code is fully operational and platform tested, it is ready to put into SFMC.
This involves using logical, organized folder structures and naming conventions
for the template, modules, and images used in the modules. After the library is
implemented, it is ready to use and build emails!
Training >> Typically non-technical
users, specifically those unfamiliar with SFMC’s interface or email building in
general, need 2 (or maybe more) training sessions to walk them through the
process. Training session 1 is usually a walkthrough where the trainer, who
ideally is recorded, gives an overview of the interface itself, along with how
the template / modules are set up and organized. Then the trainer uses these
assets to build an email, from start to finish, including adding modules, editing
modules, and doing send previews using the completed email. At this point the
attendees should feel comfortable trying a build on their own. After they have
had a chance to build an email or two, they will likely have questions about
the interface, process, or SFMC in general, which may require another training
session. But eventually, even the most non-technical user will feel ready to
build emails autonomously, without help!
Are there any best practices?
Now that the process has been covered, here are some considerations
to make your modular library project go smoothly.
Think long term, not short term. Consider your
urgent needs, along with those you may have months from now.
Avoid the politics and ego that often accompany
these projects. No matter your role, be flexible and adaptable. Speak out
instead of just doing what you’re told. Each person involved can play a big
role in the success of the overall project, and politics and ego simply get in
Go big, not small. Better to have a big library
and lots of options than to limit yourself with a small library and have to
constantly expand it and repeat the entire process any time a new scenario
emerges. Aim for 50+ modules to force yourself to stretch a bit and aim high.
Make sure that the strategy and content stages
are done properly and have been well thought out. Otherwise designers and
developers will end up spending much more time modifying designs and code based
on changing requirements, instead of having those requirements well-defined
from the start.
Create variety in your library. Since there is
no limit to how many modules you can have, why not make multiple headers/footers
with different feels, such as different layouts, styles, or content. Make
modules with variants and options. Not only will this support more use cases
for your marketing team, but it will also create more visual variety for your
audience, likely increasing engagement and conversions.
Involve the whole team through the whole
process. Designers and developers, though their role happens later in the
workflow, need to have a say from the beginning. Designers can help provide
guidance on wireframing content and making sure the content requirements will
lead to good designs. Developers can ensure that designers aren’t designing
things that are not possible to be coded, or that will be hard for end users us
build emails from.
No matter how well built the template system,
the end user building the emails needs to be capable and willing to learn.
While the SFMC template system isn’t rocket science to learn, it will require
some effort on the part of the end user to become skilled at using the tools it
provides. The goal of the team should be to make this very easy for the end
user, and the team should enable them to ask questions, learn, and even expand
their hard skills like html to enhance their abilities and independence from
Understand that SFMC has limitations, primarily
in its visual editor. When non-technical users are building emails, they will
find scenarios where the visual editor in Content Builder either doesn’t allow
a way to do something (like change padding for instance) or does allow it but only
in the visual editor (like changing a background image). To avoid frustration
with the product limitations, understand them up front and don’t blame the
What about maintenance,
expansion, and documentation?
No matter how well you architected and implemented your
initial module library, over time things will change and use cases will arise
where you didn’t (and couldn’t possibly have) foresee email or content
requirements that your current library doesn’t support or fully support.
Maybe you’re rebranding. Maybe you’re looping in another
business line. Maybe your new VP of Marketing has a new vision for where to
take the email program. Maybe you’re expanding your email program. Whatever the
change, know that you can always revisit this process as an expansion effort on
your library, which by no means is etched in stone.
Additionally, maintenance may be needed on your library.
Maybe some modules aren’t used that you thought would be. Maybe some modules
need variants created. Or others need to be edited. in your team again and do
some “Spring Cleaning” from time to time, ensuring that your library is always current
and ready to use at a moment’s notice.
6 months from now you may encounter new opportunities or
challenges, requiring you to expand or modify your library. Be flexible and consider
it a living entity that can grow and evolve as your business needs change.
Lastly, on large accounts with large teams, documentation
can be helpful to keep everyone on the same page in terms of expectations, and
also as a way to map out the email program as a whole in terms of marketing,
content, and designs.
Effort Worth It?
A typical modular library project in SFMC takes about a
month or less, depending on how large of a library is needed and how political
and cohesive the team involved is in implementing. But one month of work will
create the foundation for an email program that is robust, scalable, and
efficient, even for the most non-technical of end user!
Jake Gibbs is a Design Specialist at ListEngage and an expert at designing and building elegant, cross-platform compatible, mobile responsive emails and landing pages on the Salesforce Marketing Cloud. From brainstorming and ideation to polishing the final product, he loves the creative process.
Jake has worked with more than 60 clients since joining ListEngage in 2014. Some of his projects have included L’Oreal, Vanguard, Carhartt, Harvard Business School, RCI/Wyndham, Huggies, and Planet Fitness.