Marketing Cloud on Core (aka Growth and Advanced Edition) offers simple out-of-the-box form-triggered flows that are great for lead generation and straightforward scenarios, but today we’re going to dive into something more complex! In this post, I’ll walk you through the process of building a flow that checks for existing contacts and leads before creating a new lead, creates consent records, and sends an autoresponder email. Let’s get started.

Setup Notes

All testing was conducted after the Spring ‘25 release in a demo org. The standard lead duplicate rule was active and configured to allow the creation of duplicate records with alerts.

OOTB Form-Triggered Flows

Before we begin customizing the out-of-the-box flow, it’s important to understand the capabilities and limitations of Form-Triggered Flows. This helps guide decisions concerning when customization is necessary.

OOTB Form-Triggered Flow without Lead Matching

This is the most basic flow and is what’s automatically generated when the Signup Form template is selected during the campaign creation process. No modifications were made to the flow, outside of configuring the “CreateConsent” element.

Test Results 

Summary 

In all three test scenarios, a new lead record was created leading to duplicates in Salesforce. 

OOTB Form-Triggered Flow with Lead Matching

In this test, a very slight, but important, modification was made to the flow—the “Check for Matching Records” option was enabled in the “LeadCreation” element.

Test Results 

Summary 

This small update made a significant improvement. The flow now prevents the creation of duplicate leads when an existing lead submits the form. However, a new lead record is still being created when an existing contact submits the form.

This occurs because flows are object-specific, and the OOTB flow only references the lead object. It lacks visibility into the contact object, so it creates a new lead if an existing lead is not found. In short, the flow is performing exactly as it’s designed to.

OOTB Form-Triggered Flows Summary

The OOTB Form-Triggered flows support simple use cases, but it’s important to be aware of the potential for duplicate record creation. These flows are intended as a starting point for marketers and should be customized to meet more specific requirements.

Form-Triggered Flows with Autoresponder Emails

Use Case

Your company just released its latest white paper, which is expected to have great appeal to potential and existing customers alike. The marketing team is posting the white paper on the website as a gated asset. In addition to redirecting users to a “Thank You” page, marketing also wants to send an autoresponder email. The autoresponder not only provides the recipient with easy access to the white paper should they want to view it again later but also serves as a way to validate the email address that was provided.

Why do we need to customize the OOTB flow?

Since the white paper will “appeal to potential and existing customers,” we know that the form will be submitted by new visitors, existing leads, and existing contacts. If we simply added a “Send Email Message” element to the OOTB flow, we could send the autoresponder email, but we would create new leads in Salesforce if an existing contact submitted the form.

The flow needs to be customized to check for existing contacts, in addition to existing leads, before creating a new lead and sending the autoresponder email.

The Finished Product

Before we walk through the build of the flow, let’s first take a look at the finished product. Then, we’ll review each element, discuss its function, and why it’s needed.

CreateProspect 

Function: Creates a new record on the prospect object for each form submission.
Reason: Flows using the “Send Email Message” element are required to have a “Create Records” element directly after the Start element. The “Create Records” element must create a record on the Contact, Lead, or Prospect object.

If we created records on the Lead object, we would be in the exact same situation as the OOTB flow: we would create duplicate leads when contacts submitted the form. If we created records on the Contact object, we would bypass the Lead object, and submissions from new visitors would be created as contacts.

The Prospect object was introduced as part of the Spring ‘25 release and is designed to keep unqualified prospects unassigned until they meet your organization’s agreed-upon lead requirements. We can satisfy the flow requirement by creating a record on this object without involving the sales team or triggering automations.

GetContacts 

Function: Retrieves all contacts who match the form submission based on the provided email address and last name.
Reason: Before we can check if a form submission is an existing contact, we must first give the flow visibility into contact records so that we have something to compare against in the “Decision” element.

Contact Match 

Function: This “Decision” element is used to check if the form submission is an existing contact. If a match is found, the existing contact record is updated. If a match is not found, the existing lead record is updated (if one is found), or a new lead record will be created.
Reason: Prevent the creation of duplicate leads when existing contacts submit the form.

UpdateContact 

Function: Update existing contact records based on data included in the form submission.

Reason: Update the contact record with the most current data.

LeadCreation 

Function: Create new lead records or update existing lead records based on data included in the form.

• Important: Make sure “Check for Matching Records” is enabled. 

Reason: Create/update lead record with the most current data.

CreateConsent 

Function: Creates a consent record based on the contact point for the selected channel and subscription.
Reason: Consent records are required for sending promotional emails from Marketing Cloud on Core.

TransactionalEmail 

Function: Transactional emails are non-promotional, immediate, and automated communications sent in response to a user’s action or interaction.
Reason: In this use case, the transactional email is used to send the ungated link to the white paper for future reference. Transactional emails can be used as long as they contain no promotional elements.

DeleteProspect 

Function: Deletes the prospect record created by the first element.
Reason: This step is optional but recommended. Since a prospect record was created solely to satisfy the requirement of having a “Create Records” element first, deleting the record helps keep the org clean. If you are using the prospect record for purposes beyond fulfilling this requirement, you can skip this step.

Other Use Cases & Next Steps

This structure can be applied and adapted to other use cases where there is a need to send autoresponder emails to leads and contacts without creating duplicate records. Examples include flows that create tasks or campaign member records in addition to sending autoresponders. 

Flows might seem challenging at first, but marketers will love them once they gain more experience. The key takeaway is to get hands-on, test, and don’t hesitate to ask for help if needed. Personally, I can say that I received a lot of support from my friends at Sercante when I was starting out, and I still do today!

Original article: Step-by-Step Guide: Creating Marketing Cloud on Core Form-Triggered Flows with Autoresponder Emails

©2025 The Spot. All Rights Reserved.

The post Step-by-Step Guide: Creating Marketing Cloud on Core Form-Triggered Flows with Autoresponder Emails appeared first on The Spot.

As part of the Winter ‘24 release, Account Engagement users gained the ability to copy assets to and from Account Engagement Sandboxes. This allows marketers to test automations and assets before pushing them to their Production Account Engagement org. It also allows them to pre-populate Sandboxes with assets so they don’t have to start from scratch. 

The Account Engagement to Sandbox-to-Production Flow currently supports seven asset types: 

1. Email Templates
2. Custom Redirects
3. Custom Fields
4. Files
5. Engagement Studio Programs
6. Layout Templates
7. Form Handlers

Account Engagement Sandbox-to-Production Flow Installation Instructions

To start using the Sandbox-to-Production flow, you will need to create a Connected App and two named credentials. 

Step 1: Create the Connected App in the Sandbox Org

This provides the interface to authenticate into an org.

1. In your source org (Production), grab the Sandbox Asset Auth Flow callback URL.
   • Go to Setup > Auth. Providers
   • Open the Sandbox Asset Flow Auth
   • Copy the Callback URL, you will need this shortly
2. In your Sandbox org, navigate to Salesforce Setup > App Manager and then select New Connected App.
3. Configure the Connected App as follows:
   • Connected App Name: MCAE Sandbox to Production
   • Contact Email: Email Address of the admin who will be managing the Sandbox-to-Production promotion process. 
   • Enable OAuth Settings: Checked
   • Callback URL: The Source Org Callback URL you copied in step #1
   • Selected OAuth Scopes:
     1. Access the Salesforce API Platform (sap api)
     2. Access unique user identifiers (openid)
     3. Manage Pardot services (pardot_api)
     4. Manage user data via APIs (api)
     5. Manage user data via Web browsers (web)
     6. Perform requests at any time (refresh token, offline_ access)
   • Require Secret for Web Server Flow: checked
   • Require Secret for Refresh Token Flow: checked
4. Select Save
   • Note: It may take 10-15 minutes for the connected app to be ready for authentication.
5. Select Manage Consumer Details
6. Copy your Consumer Key and Consumer Secret for later use.

Step 2: Update Auth Provider in Production Org

This handles the authentication process.

1. In your Source Org (Production), enter the Consumer Key and Consumer Secret from your Connected App
   1. Go to Setup > Auth. Providers
   2. Open the Sandbox Asset Flow Auth
   3. Select Edit
   4. Enter the Consumer Key and Consumer Secret
2. Select Save

Step 3: Create an Account Engagement API Named Credential

This establishes access via an integration user to the Account Engagement API.

1. In your Source Org (Production), navigate to Setup > Named Credentials
2. Select New Legacy
   1. Note: Do not select “New”, it should be “New Legacy”!
3. Configure the Named Credential as Follows:
   1. Label/Name: MCAE API Access
   2. URL: https://pi.demo.pardot.com
   3. Identity Type:  Named Principle
   4. Authentication Protocol: OAuth 2.0
   5. Authentication Provider:  Sandbox Asset Flow Auth
   6. Scope: Pardot_api refresh_token
      1. Make sure this says “pardot_api refresh_token”, not just “api refresh_token”

7. Start Authentication Flow on Save: Checked
8. Generate Authorization Headers: Checked

2. Select Save
3. Log back into the Sandbox org with your credentials. Doing so finalizes the authentication for the named credential.

Step 4: Salesforce Metadata API Named Credential

This establishes access via an integration user to the Metadata API to retrieve BU details.

1. In your Source Org (Production), navigate to Setup > Named Credentials
2. Select New Legacy
   • Note: Do not select “New”, it should be “New Legacy”!
3. Configure the Named Credential as Follows:
   • Label/Name: Metadata API Access
   • URL: https://mydomain—sandboxname.sandbox.my.salesforce.com, but replace “mydomain” and “sandboxname” with the value from your sandbox url.
     1. ex: https://sercante–testing.sandbox.my.salesforce.com
   • Identity Type:  Named Principle
   • Authentication Protocol: OAuth 2.0
   • Authentication Provider:  Sandbox Asset Flow Auth
   • Scope: api refresh_token
   • Start Authentication Flow on Save: Checked
   • Generate Authorization Headers: Checked
4. Select Save
5. Log back into the Sandbox org with your credentials. Doing so finalizes the authentication for the named credential.

Running the Flow

Before you run the flow, ensure the destination org has at least one Folder, Campaign, and Tracker Domain. If your destination does not have these assets, you will run into issues with the flow.

1. In your Source Org (Production), navigate to Setup > Flow
2. Open the Account Engagement Sandbox-Production Bulk Asset Copy Flow
3. Select Run
4. For “Named Credential for Salesforce API Access” select the Metadata API Access (step 4 above)
5. For “Named Credential for Account Engagement API Access” select the MCAE API Access (step 3 above)

6. Select Next
7. Select your direction of Copy
   • From a Sandbox to Production
   • From Production to a Sandbox
8. Select your Production and Sandbox Business Units

9. Select Next
10. Select assets to copy over, select Next

11. Confirm the Assets, select Next
12. Select your Folder, Campaign, and Tracker Domain for your new assets
13. Select Copy Assets
14. The final screen will provide details regarding the copied assets as well as let you know if there were any errors.

Considerations for Using the Sandbox to Production Flow

Since this is a new capability for Account Engagement, there are some details and settings that do not come over when copied. I thoroughly tested each asset type and below are the considerations that I found.

Tracker Domain

You must verify the Tracker Domain in your Sandbox. Otherwise, Email Templates, Custom Redirects, and Files will fail when the unverified Tracker Domain is selected. You can use the default tracker domain (go.pardot.com) but this will cause issues when copying over any Custom Redirects with a Vanity URL.

Email Templates

• When copied, the email sender will be replaced by a General User with the email replace@example.com. This applies even if you have a sender hierarchy specified using “Assigned User” and ‘Account Owner.”

• Email Templates containing Dynamic Content will not copy over. This is because dynamic content is unique to the Business Unit. Even if you have the same Dynamic Content in each Business Unit, they will have a different asset ID and merge tag.
• If the Email Template contains a merge tag for a field that is not in the destination org, the flow will fail. Ensure all needed fields are copied to the destination org before copying over any assets that use custom field merge tags.

Custom Redirects

A Custom Redirect’s Completion Action(s) will not copy over, however, the Google Analytics Parameter values do.

Files

During my testing, I tested PNG, JS, JPG, GIF, SVG, CSS, and PDF file types, and all successfully copied over!

Custom Fields

When you copy custom fields, only the following information comes over:

• Field Name
• Field API Name
• Field Type

Engagement Programs

• When you copy an Engagement Studio Program (ESP) only the ESP structure is copied. The Recipient List, Suppression lists, Send days/times, and “Allow prospects to enter more than once” settings do not come over and will need to be reconfigured.
• The assets specified in a Trigger or Action node, such as email templates, landing pages, and forms, will need to be reselected in the new ESP. However, the number of wait days specified in the node will copy over. 



• If an Action node looks at a Prospect field (i.e. Prospect default field “Job Title” is not blank) and that field is in both Production and Sandbox, then the node will be copied to the new ESP with the field and value/settings specified. If the field does not exist in both Production and Sandbox, then the Action node will still be in the ESP but the field and value/settings will need to be reconfigured. 

Layout Templates

If you use Dynamic Content within your Layout Templates, keep in mind that the Dynamic Content will not come over when the Layout Template is copied. You can copy the Dynamic Content over as a separate asset, but you will still need to edit the Layout Template in your destination Business Unit to make sure it has the correct Dynamic Content ID.

Form Handler

• Ensure all the fields on the Form Handler exist in the environment you are copying to before copying the Form Handler.
• If your Form Handler only uses Default Prospect Fields, then all of the fields will come over when the Form Handler is copied. However, if your Form Handler uses any Custom Prospect Fields, the custom field needs to be in the destination org before you copy the Form Handler.
• When copied, the Success Location and Error Location details will copy over to the new asset. Completion Actions do not copy over.

Now it’s even easier to work with Account Engagement Sandboxes!

This new Flow is a huge step toward making Account Engagement Sandboxes user-friendly for testing and staging. What other capabilities would you like to see in this Flow? Let us know in the comments!

Original article: How to Copy Account Engagement Assets to Sandbox

©2025 The Spot. All Rights Reserved.

The post How to Copy Account Engagement Assets to Sandbox appeared first on The Spot.

Salesforce is upping their game in the race to incorporate the latest generative AI tools into their products. Announced during Salesforce Connections on June 7, Marketing GPT and Commerce GPT are coming to Salesforce customers using Marketing Cloud and Commerce Cloud. 

The features are gonna make it easier for marketers to reach the right audiences and generate emails, and commerce teams will create better shopping experiences and customer journeys. But, the best part is that both Marketing GPT and Commerce GPT can be connected to Data Cloud — meaning the tools can do their thing using data from any source.

History of Salesforce in the GPT game

Both Marketing GPT and Commerce GPT are dependent on Einstein GPT, which is the generative AI version of Einstein. 

For a little back story, Salesforce Einstein is the machine learning model the company rolled out in 2016 to analyze large sets of CRM data. So, Salesforce has been on the AI train for a while already. 

Einstein can do things like predict which customers or sales leads are likely to buy by looking at data from a bunch of sources. Or it can analyze data to determine the best time to send emails to your lists.

You can get it in Marketing Cloud Engagement and Account Engagement, Sales Cloud, Commerce Cloud, Experience Cloud, and Service Cloud, along with other platform tools.

In March 2023, Salesforce released Einstein GPT, which combines the machine learning model Salesforce developed with the chatbot from generative AI company OpenAI. (On a side note, Salesforce is going heavy on the AI devotion and has already invested $250 million into other AI technology companies.)

So, how are Marketing GPT and Commerce GPT related to Einstein GPT?

Both Marketing GPT and Commerce GPT are powered by Einstein GPT — the AI-powered set of solutions that marries Salesforce AI with OpenAI’s technology. They are both iterations of Einstein GPT that are tailored for the respective clouds. Stay tuned because we’re seeing GPT features getting infused across all Salesforce clouds in addition to these two.

What capabilities do Marketing GPT and Commerce GPT have?

Both of the sets of features combine generative AI capabilities, which use data from OpenAI, with Salesforce Data Cloud. That means you can use customer profiles in Data Cloud that include data from any source in real time. And while you don’t have to use Data Cloud to take advantage of the Salesforce GPT features, you’ll definitely be able to do more if you have it.

So, what exactly can you do with Marketing GPT and Commerce GPT?

Marketing GPT Capabilities

We’re really gonna be cooking now by giving the people super valuable experiences through email and content marketing. We already have Einstein features in our marketing back pocket, but now we’re throwing GPT into the overall mix. That means we can use conversational language prompts to get Marketing Cloud to do things for us. 

I mean, it’s not going to organize all those random newsletter graphics you’ve been uploading to Account Engagement without using a naming convention (yet???). But it will do things like analyze the data you have and use that information to predict the best ways to improve your emails. 

Source: Salesforce

Here’s what Marketing GPT can do (so far):

• Segment Creation | generally available Oct. 2023
  This is a whole new fancy way to build your audience segmentation strategy. You can tell Marketing Cloud to create audience segments for you using natural language prompts, and it will help you to improve your targeting using AI recommendations and audience data that’s in Data Cloud.

• Email Content Creation | generally available Feb. 2024
  Ok, so I’m gonna have to see this one in action, but Salesforce said this feature can “reduce writing workload” by creating auto-generated emails. It can potentially be a big one for marketing teams that have the content but stumble with their email marketing.

• Segment Intelligence for Data Cloud | generally available Oct. 2023
  This adds a fancier twist for tracking ROI. Segment intelligence combines first-party audience data, revenue data, and paid media data to show you exactly how your campaigns are doing in relation to your audience segments. 

• Rapid Identity Resolution, Segmentation, and Engagement | generally available Aug. – Oct. 2023
  Salesforce is going heavy on the ‘transform at the speed of your customer’ theme. The mouthful that is this feature basically keeps Data Cloud segments updated in real time so messaging is always relevant and timely.

• Typeface content platform | GA date not given yet
  Using a third-party content generator called Typeface, marketers can create branded visual assets (like email graphics or social cards) inside Salesforce. Stay tuned for this one cuz it could be huge.

These are the features that Salesforce outlined during the announcement, but we’re sure the list will grow with each Salesforce release.

Commerce GPT Capabilities

We’re also getting a bunch of generative AI features for B2C companies that use Salesforce tools for commerce. These are especially cool because ecommerce customers can be a fickle bunch. Getting them exactly what they want when they want it makes all the difference.

Source: Salesforce

Here’s what Commerce GPT can do (so far):

• Goals-Based Commerce | generally available Feb. 2024
  This is one of those a-ha tools for businesses with big growth goals. It unites Data Cloud, Einstein, and Flow to lay out everything commerce companies need to do to reach their goals. Users give it a goal, like increase average order value (AOV) by XX%, and it gives recommendations on how to get there.
  
• Dynamic Product Descriptions | generally available July 2023
  Okay, so we’ve seen how serving up product recommendations based on customer preferences has shaken things up for commerce companies. But now we’re gonna be taking it even further by introducing dynamic copy capabilities for product descriptions. It could be a serious game changer.
  
• Commerce Concierge | generally available Feb. 2024
  Not all of the Commerce GPT features are specifically for Salesforce users. Online shoppers can use Commerce Concierge to find what they need using language prompts across channels from online stores to SMS messaging.

Comments on generative AI + Salesforce from the peanut gallery

My two cents: My mind immediately goes to the content creation features of Marketing GPT. There is SO MUCH copywriting that goes into marketing. And we’ve seen a whole bunch of copywriting GPT tools pop up in the last year, like the free Stensul email toolkit or paid ones like GrammarlyGo. Some people are naysaying the tools in fear that they will replace copywriting jobs, but I don’t think that’s the case at all.

In my experience, leaner marketing teams rarely have dedicated copywriters. Those responsibilities are usually lumped into other marcom roles. I see the tools giving marketers the ability to edit copy instead of writing from scratch. Then, they can have bandwidth to dig deeper with their messaging and present higher quality work that hits their audience in the feels. And being able to do that inside Salesforce just sweetens the whole deal.

I opened the floor to my teammates about what they think about Marketing GPT and Commerce GPT, and here’s what they had to say.

Cate Godley

“I’m excited to see how Marketing GPT can help marketers to craft better subject lines and calls to action to increase engagement with content. There are so many ways to use generative AI to inspire creativity in our marketing efforts, and I can’t wait to see how people are using these tools in new and exciting ways.”

Courtney Cerniglia

“As marketers, we’re constantly asked what content is resonating most with customers, what action will increase likelihood to purchase, and how we identify our highest value leads. Marketing GPT is going to help prove our assumptions and give us the data in real-time, across platforms, so we can quickly pivot and personalize experiences for customers.”

Mike Creuzer

“There have been a few inflection points where human knowledge growth hockey sticked. Gutenberg press took centuries, computers took decades, the internet took years, and this generative AI appears to be taking… months?

According to the 2023 Connections Keynote, there were 1 million users in two months for ChatGPT (if I remember correctly).

We are at the start of the next great change in pace of human knowledge and communication.

2023 is the year where AI is no longer hidden away behind RFID badged doors and is widely available to EVERYBODY in a usable, general way.

In business, AI has been baked into the tools that we use for many years now. But it’s been a one trick pony. It’s now anything WE want it to be, not just what our vendors built.”

Continue the conversation 

What are your thoughts on Salesforce and generative AI? Any hot takes? Tell us about it in the comments, or reach out to team Sercante to see how the tools fit into your overall marketing and operations strategy.

Original article: Salesforce Announces Marketing GPT and Commerce GPT

©2025 The Spot. All Rights Reserved.

The post Salesforce Announces Marketing GPT and Commerce GPT appeared first on The Spot.

If you’ve ever experienced email bounces in Pardot (and chances are you have), you’ll know that reporting on and exporting them has been a labor-intensive task. 

That all changes now.

As part of the Summer ‘22 Release, marketers have been blessed with a new tool for Marketing Cloud Account Engagement (Pardot) called Email Bounce Report.

It’s a feature that shows who, when and why prospects bounced. And it also allows you to export all that insightful data.

That’s right, our prayers have been answered. We no longer need to manually pull this data from each and every email report.

What is an email bounce rate?

First, let’s understand what a bounce rate is. 

Your org’s bounce rate is the number of hard bounces plus soft bounces, divided by the number of emails sent, multiplied by 100. 

In B2B marketing, anything below 10% is considered a good bounce rate. 

It’s good practice to monitor your bounce rate. And this report helps you do just that!  

Who can get the Pardot Email Bounce Report?

This report is available on all Pardot editions, and it includes bounced email addresses from both Pardot Classic and Lightning. 

Not upgraded to Pardot Lightning App? Here’s your nudge to do so.

What do you get in the report?

The report is pretty comprehensive and shows bounce data for ALL Pardot prospects. We’ll go into some of the use cases in another blog post. 

From total number of email bounces (filtered by date) to bounce reasons, this report has it all. And yes, all of the bounce rate report data is exportable. 

Found under marketing reports, you are greeted with a chart illustrating, 

• All emails sent over the last year – one year from todays date – so if its the 12 May 2022, you can go back to 12 May 2021. Personally, I’d hope this is amended in future updates as it would be useful to see further than the last year in some cases.  
• Total emails sent
• Total bounced & delivered
• Bounce by type – Soft vs. Hard

Scroll down, and you get to the good stuff… the bounce details, including bounce reason. 

It’s no good seeing the number of bounces you’ve received if you can’t do anything about it. Filtered by bounce type and date, the Email Bounce details table tells you: 

• Prospects who have bounced 
• Email addresses and company names
• Email subject 
• Bounce type
• Bounce reason
• Bounce date
• Email name – linked 
• Email send type and template name

Why is the Pardot email bounce report so useful?

1. Understand why your emails are bouncing

From full inboxes, invaild email address and none responsive servers, there are a number of reasons why your emails may bounce. This report helps you understand those reasons and potentially act on them.

Types of bounces

• Soft bounce – Occurs when an email is recognized by the recipient’s mail server but is returned to the sender because the recipient’s mailbox is full or the mail server is temporarily unavailable.
  
  These prospects may be able to receive emails at a later time. However, after an email soft-bounces five times, Pardot will mark the prospect as undeliverable and suppresses them from receiving emails from you. 
• Hard bounce – Occurs when the prospect’s email address is invalid, the domain name does not exist, or the sender is suspected as spam and/or has been blocked. Prospects with a hard bounce are no longer mailable. 
• Bounce reasons – If you’re able to resolve the email bounce issue, you can reset the bounce count on the prospect record and start mailing them again. 

2. Spot trends and take action

Use the report and export feature to filter and identify trends that may be contributing to you bounce rate, such as:

• Particular templates that continuously bounce
• Subject lines that cause bounces – Spammy subject lines?
• Dates of email sends – Think back to the Google outage way back December 2020. Are there any significant dates when bounces were high?
• Certain companies/ email domains – Contact the recipient and ask them if they’ve configured an email rule that forwards incoming email messages from you to another destination. Their rule could have tried to send a copy of your message to a bad email address. Or, have you simply misspelled the address/email domain?

3. See the bigger picture

Ever sent an email and thought “wow, that bounce rate was high!” You may have wondered if this was an isolated incident or if bounces were in fact an issue in your org? 

Often marketers see a few emails with high bounce rate and assume they are destined for failure when it comes to getting their message into the inbox of prospects. Using this report, you can see the bigger picture. Then, you can understand how many bounces you have IN TOTAL out of all the emails sent in the last year. 

4. Keep your Pardot data clean

Bounces often relate to the quality of your data and a low bounce rate overall indicates a healthy and clean org. Knowing how big of a problem bounces may (or may not) be can help with keeping your org clean and relevant. 

Using the “Reset” feature found on individual prospect records you can reset bounces (hard and soft) and give yourself a second chance. 

Still no luck? Consider removing these prospects, particularly if the bounce reason is permanent. 

5. Avoid Salesforce account suspension

Salesforce is super serious about permission-based marketing. And its reputation as an email service provider, as well as your reputation as an email sender, is why they monitor accounts with bounce rates over 10% (as well as high spam complaint rates). 

If Salesforce notices an issue with either of these numbers, they can suspend email sending from your account. 

What can you do to lower your email bounce rate?

No email service provider can ever guarantee your deliverability rates — that’s down to your email practices and behavior. 

Here are some things you can do to help with your email sending reputation and lower those bounce rates.

1. As above, understand why your emails are bouncing and take action.
2. Set up email authentication.
3. Build email sending lists using a confirmed opt-in process
4. Don’t purchase data without getting permission to send emails to the list.
5. Clean your database regularly & check that email addresses are spelled correctly.
6. Make sure your emails aren’t spammy.

Understanding email bounces is a big win for marketers

Armed with the data behind the bounces, this report is a win for marketers serious about their email sending reputation. 
However, if you’re left feeling confused, worried or overwhelmed by the numbers, reach out to the Sercante team to see how we can help.

Original article: Salesforce Summer ‘22 Release: Review Email Bounce Data in One Report

©2025 The Spot. All Rights Reserved.

The post Salesforce Summer ‘22 Release: Review Email Bounce Data in One Report appeared first on The Spot.

The Salesforce Winter ‘22 release introduced the ability to create a custom Lightning Web Component (LWC) for Lightning Email Content, and with Spring ‘22 we have the same ability for Pardot Lightning Email Templates.

With this new feature, you can create components for standard areas of emails, such as footers or headers. Or, use it for more complex items, such as displaying upcoming events or gathering prospect feedback.

In this post, we will present the code for 5 different LWCs, walking you through the most simple example and incrementing from there.

• Simple hard-coded HTML
• Hard-coded HTML, which includes a merge field
• Allow someone creating an email to provide text, which is placed into the HTML
• Present a picklist of values, with HTML being rendered based on choice
• Pull information from an Open API, and then place it into the email

It is important to note that these custom components behave differently than Pardot Snippets or Dynamic Content. Unlike those features, when you change the LWC, existing Pardot Email Content and Templates do not get automatically updated. You need to go into each one to refresh them.

Because we all like analogies, think of the LWC as a rubber stamp and the Pardot Email Content & Template as paper. We can craft the stamp however we like (from simple to very complex), and once it is ready it will stamp the ink (HTML) onto the Email Content or Template. Changing the stamp does not change the ink already on the paper — you need to use the new/adjusted stamp and do it again.

Feel free to check out the code project in our github repository. If you aren’t already familiar with Salesforce Lightning Web Components, check out this Trailhead Quick Start.

Simple hard-coded HTML

This example is a pretty good one for anyone to get started. It demonstrates what is needed to at least have something work at the most basic level. Consider it the Hello World of Custom Email Components. In our github repository, this is the fixedAddress component.

This type of custom component is great to use for standard sections of your emails that do not change with each send. For example, the copyright notice, legal disclaimer, unsubscribe language etc.

At a minimum, our LWC will need 3 files:

1. .html -> The HTML which will become rendered and stamped into the Email Content/Template
2. .js -> Any coding required to support the component
3. .js-meta.xml -> Salesforce Metadata, enabling this component to be used in Email Content/Templates

First, we will explore the Salesforce Metadata.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>52.0</apiVersion>
    <isExposed>true</isExposed>
    <masterLabel>Fixed Company Address</masterLabel>
    <targets>
        <target>lightningStatic__Email</target>
    </targets>
</LightningComponentBundle>

Some key notes:

• isExposed (line 4) is needed to tell Salesforce that this component can be displayed in the Component Toolbox
• masterLabel (line 5) is the name to display in the Component Toolbox
• target = lightningStatic__Email is needed to tell Salesforce that this component can be used in the Lightning Email Builder. Other examples have a bunch of other targets, these are not needed and may result in your component showing up in unexpected places.

Next we will look at the JavaScript.

import { LightningElement } from 'lwc';

export default class FixedAddress extends LightningElement {}

Because our example is mostly hard-coded, there is nothing of value here. As we evolve, we’ll start seeing this get built out.

Finally, the HTML.

<template>
  <p>Our Address is: 123 Main St, Atlanta GA, USA</p>
</template>

Again, very simple. When the email HTML is rendered, everything in between the <template> tags will be written.

Here’s what it looks like in the builder. Once the component is added to the email, it is just simple text that is rendered.

Hard-coded HTML, which includes a merge field

This example is nearly identical to the previous one, so we will skip showing the JavaScript and the Metadata.  In our github repository, this is the fixedWithMergeFields component.

Straight to the HTML:

<template>
 <p>Hello {{{Recipient.FirstName&#125;&#125;&#125;, 
     I hope you are having a great time learning 
     about our products and services.</p>
</template>

What you might notice is how the merge tag has been written. Due to some very technical reasons, we can’t just use the usual {{{FIELD}}} syntax, we have to instead “escape” the closing curly brackets to make the LWC gods happy. This appears to only be the case when the merge tags are placed into the HTML file, as normal syntax can be used when the merge tags appear in the JavaScript.

Here’s what it looks like in the builder. Similar to the previous example, you get text that cannot be adjusted.

Allow someone creating an email to provide text

Now we are going to start allowing the user of a custom component to provide their own values. In our example we are going to start off a bit slow, simply allowing them to provide some text. In our github repository, this is the guidedManualEntry component.

We need to decide which “attributes” (or values) we want a user to provide. For this example, we will ask for a Title, an Image URL, and a Description. 

First, let’s take a look at our JavaScript. It needs to define these attributes.

import { LightningElement, api } from 'lwc';

export default class GuidedManualEntry extends LightningElement {
  @api
  title=""
  @api
  imageUrl=""
  @api
  description=""
}

You will note that each “attribute” has a variable name and the @api annotation. This annotation tells the LWC system that these can be referenced by the HTML file as well as our metadata file.

Next, we will tell our Metadata file to prompt the user to fill in these values.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
  ...
  <targetConfigs>
    <targetConfig targets="lightningStatic__Email">
      <property 
        label="Title"
        name="title"
        type="String"
        default="Title of Entry"
        required="false" />
      <property 
        label="Image URL" 
        name="imageUrl"
        type="String"
        placeholder="https://"
        description="Enter Image URL for this image. Be sure that it is a secure URL starting with https://"
        default="https://via.placeholder.com/575x150"
        required="false" />
      <property 
        label="Description"
        name="description"
        type="String"
        default="Description of Entry"
        required="false" />
    </targetConfig>
  </targetConfigs>
</LightningComponentBundle>

Ok, that’s a lot! What we are doing is giving our lightningStatic__Email target a list of properties to present on the right hand side of the Lightning Builder when someone wants to use our component.

Each property (to be presented) has a bunch of levers we can adjust to enable our user to give us what we need. Let’s break down the ones we use here:

• label > basically a form field’s label
• name > the name of the attribute in the LWC’s JS file
• type > the type of input to present. For an email builder our current choices are:
  1. Boolean > displays a checkbox
  2. Integer > displays a text input allowing digits
  3. String > displays a text input allowing any character
  4. Color > displays a color selector
  5. HorizontalAlignment > displays a horizontal alignment selector
  6. VerticalAlignment > displays a vertical alignment selector
• default > the default value to use when a new component is created
• required > whether or not a value is required to save the component

The Salesforce LWC Developer documentation is a great resource for getting more details on all the abilities of the LWC metadata file.

Now that we are getting values from a user, we need to display them in the HTML!

<template>
  <h3>{title}</h3>
  <img src={imageUrl} />
  <p>{description}</p>
</template>

Here we are using LWC variables to place the values provided by the user. The syntax for this is the variable name (that has the @api annotation in your JavaScript file) wrapped by a single set of curly brackets. 

Now we can kind of understand why our HML syntax which includes 3 sets of curly brackets doesn’t really work, we can’t mix the two.

Here’s what this looks like in the builder. We are asking for the user to provide values within the section on the right hand side. 

You can combine your Custom Components with Layout components to build a nice consistent email.

Present a picklist of values, coming from APEX

Now things start to get interesting. We will tie our LWC to some APEX code, opening our world of options. Before we get started, it is important to know that you don’t have to use APEX to present a picklist of options, it can entirely be done in the Metadata. Sadly we can’t show every variation of example. In our github repository, this is the htmlPicklist component.

Before we get started, we want to give credit to the original author of this example to jrattanpal on github. We simply made some minor changes to enable it to be used as a learning example.

First, we need an APEX class which will provide the options that are available.

global class HTMLSources extends VisualEditor.DynamicPickList{
    
  global override VisualEditor.DataRow getDefaultValue(){
      VisualEditor.DataRow defaultValue = 
          new VisualEditor.DataRow('--Select--', '');
      return defaultValue;
  }

  global override VisualEditor.DynamicPickListRows getValues() {
      VisualEditor.DynamicPickListRows options = new VisualEditor.DynamicPickListRows();
      options.addRow(new VisualEditor.DataRow('HTML Option 1', '<h1>Sample 1, simple header</h1>'));
      options.addRow(new VisualEditor.DataRow('HTML Option 2', '<h3>Sample 2, smaller heading</h3>'));
      options.addRow(new VisualEditor.DataRow('HTML Option 3', '<h4>Sample 3, multiple blocks of HTML</h4><div>hello<p>testing html picklist</p></div>'));
      options.addRow(new VisualEditor.DataRow('HTML Option 4', '<h2>Hello Trailblazer</h2>'));
      options.addRow(new VisualEditor.DataRow('HTML Option 5', '<h2>This was swell</h2>'));
      return options;
  }
}

Note that the class extends VisualEditor.DynamicPickList, which requires us to provide 2 method overrides.

• getDefaultValue -> provides the value selected when the component is first added to an Email. In our example above we simply prompt for a choice.
• getValues -> provides all of the options that a user can pick from. To our knowledge you can’t retrieve a list of values dynamically based on another input from the user, though if this changes in the future be sure to let us know!

Now that we have APEX which can provide our values, let’s set up our LWC. We will start with our JS.

import { LightningElement, api } from 'lwc';

export default class HtmlPicklist extends LightningElement {
  @api
  set htmlValue(value) {
    if (this.attachmentPoint) {
      this.attachmentPoint.innerHTML = value;
    }
    this._htmlValue = value;
  }
  get htmlValue() {
    return this._htmlValue;
  }
  renderedCallback() {
    this.attachmentPoint = this.template.querySelector('div[ishtmlcontainer=true]');
    this.attachmentPoint.innerHTML = this.htmlValue;;
  }
}

The approach here is a little bit different than all the other examples. The goal is to take the “htmlValue” (which comes from APEX) and have that HTML be the entire HTML that gets stamped onto the Content/Template. This keeps our LWC HTML very lightweight and gives full control over the HTML to APEX (or wherever the APEX is getting the value).

Next, we will tell our Metadata file to prompt the user to choose one of the options.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata" fqn="banner">
  ...
  <targetConfigs>
    <targetConfig targets="lightningStatic__Email">
      <property 
        name="htmlValue"
        label="Pick an HTML Sample"
        type="String" 
        required="true" 
        datasource="apex://HTMLSources"/>
    </targetConfig>
  </targetConfigs>
</LightningComponentBundle>

Some of our properties are similar to the previous example, however we introduce a new one.

• datasource > 

As for the HTML file, it simply has a DIV that the JS can grab onto and fill.

<template>
  <div ishtmlcontainer="true" lwc:dom="manual"></div>
</template>

Here’s what it looks like in the builder. Similar to the previous example, the right hand side allows us to make a choice, and once made the content of our component is rendered.

Pull information from an Open API

This is the last of our examples, and it goes all out. By using an Open API, we don’t need to worry about authentication and all the additional steps to set it up in Salesforce. In our github repository, this is the starWarsCharacter component.

Similar to the previous example, we will start with some APEX. While there can be a lot going on here, the end result of the APEX is to provide a JSON String representing the attributes of each Object, or dropdown choice.

global with sharing class StarWarsCharacterPicklist extends VisualEditor.DynamicPickList {

  global override Boolean isValid(Object attributeValue){
      return true;
  }

  global override VisualEditor.DataRow getDefaultValue(){
      return new VisualEditor.DataRow('--Select a Character--', 'no-character-selected');
  }

  global override VisualEditor.DynamicPickListRows getValues() {
      System.debug('Providing Star Wars Character values now!');
      return getApiOptions();
  }

  private VisualEditor.DynamicPickListRows getApiOptions() {
    VisualEditor.DynamicPickListRows pickListRows = new VisualEditor.DynamicPickListRows();

    //Make API call to StarWarsAPI and get a list of characters
    List<StarWarsCharacterServices.StarWarsCharacter> characters = StarWarsCharacterServices.getCharacterList();


    // When a choice is made from the VisualEditor, the DataRow value will be provided to the LWC
    // We are choosing to have that "value" be a JSON string, so that the LWC can parse it and
    // render the properties as it sees fit
    for(StarWarsCharacterServices.StarWarsCharacter character: characters){
      String characterInfoAsJson = System.JSON.serialize(character);
      pickListRows.addRow(new VisualEditor.DataRow(character.name, characterInfoAsJson));
    }
    return pickListRows;
  }
}

Note that the class extends VisualEditor.DynamicPickList, which requires us to provide 2 method overrides.

• getDefaultValue -> here we explicitly set a value that the JavaScript can look for, allowing it to determine if a character has been chosen or not
• getValues -> the for loop iterates over a list of options that we’ve retrieved from some other source (just so happens to be a Star Wars API with a list of characters). For each option/star wars character, we build a JSON string of all the attributes we might care about in the LWC, and then return them.

Now, let’s take a look at the JavaScript.

import { LightningElement, api } from 'lwc';

export default class StarWarsCharacter extends LightningElement {
  @api
  character = {}
  @api
  characterChosen = false
  @api
  hasFilms = false
  @api
  hasStarships = false

  @api
  set characterJson(value) {
    // the "value" is the DataRow value that came from APEX
    // in our example, this is the JSON encoded string which contains details about our character
    console.log('setting characterJson::', value);
    this._characterJson = value;
    if(value==='no-character-selected') {
      console.log('There has been no character selected yet');
      this.characterChosen = false;
    }
    else {
      try {
        console.log('A StarWars character has been selected, parsing the JSON returned from APEX');
        this.character = JSON.parse(value);
        this.characterChosen = true;
        if(this.character.hasOwnProperty('films') && this.character.films.length > 0) this.hasFilms=true;
        if(this.character.hasOwnProperty('starships') && this.character.starships.length > 0) this.hasStarships=true;
        console.log('ok done');
      }
      catch(ex) {
        console.log('got an exception trying to parse json', ex.message);
        console.log(ex);
      }
    }
  }
  get characterJson() {
    return this._characterJson;
  }
}

Some things to note with this code:

• @api character -> the JS Object which will contain all the attributes of a chosen Star Wars character.
• characterChosen -> a flag that lets the HTML know which block to render
• hasFilms -> a flag that lets the HTML know if the chosen character was in any films
• hasStarships -> another flag
• @api set characterJson -> a setter method, this is how the Email Builder will provide the JSON encoded string to the LWC once a choice has been made. The LWC then parses it and sets some of the flags.

Next, we will tell our Metadata file to prompt the user to choose one of the Characters.

<?xml version="1.0" encoding="UTF-8"?>
<LightningComponentBundle xmlns="http://soap.sforce.com/2006/04/metadata">
  ...
  <targetConfigs>
    <targetConfig targets="lightningStatic__Email">
      <property 
        label="Star Wars Character"
        name="characterJson"
        type="String"
        datasource="apex://StarWarsCharacterPicklist" 
        required="true" />
    </targetConfig>
  </targetConfigs>
</LightningComponentBundle>

It looks fairly similar to the previous example. A minor difference is that the “name” attribute specifies the setter method in the JavaScript as opposed to a property. Not a big difference, but worth calling out that you have a couple of options as you build your own.

Now, let’s look at our HTML.

<template>
  <template if:false={characterChosen}>
    <h3>Please select a Star Wars character from the picklist to the left</h3>
    <p>It may take a moment for Salesforce to retrieve the list of Characters and make them ready to display</p>
    <p>To my knowledge, it isn't possible to bind a search criteria to the API request, so all options need to be fetched first, however I'd love to know if someone figures this out!</p>
  </template>
  <template if:true={characterChosen}>
    <div class="card">
      <h2>{character.name}</h2>
      <p>
        Height: {character.height}<br />
        BirthYear: {character.birth_year}<br />
        HairColor: {character.hair_color}<br />
        HomeWorld: {character.homeworld}
        <template if:true={hasFilms}><br />Featured in {character.films.length} films</template>
        <template if:true={hasStarships}><br />Found in {character.starships.length} starships</template>
      </p>
    </div>
  </template>
</template>

We have 2 templates, the first displays some instructions when a choice has not yet been made, and the other displays information about the choice nicely. You can see we are using simple dot-notation to merge the character attributes into the HTML of the Email Content / Template.

The web developer inside of me really does prefer this approach for rendering HTML into an email, though it does prefer a consistent structured payload for each option.

Here’s what it looks like in the builder. Similar to the previous examples, the right hand side container is where the user makes their selection and, once made, the details are rendered in the email.

Custom components are platform assets, meaning they do not belong to a specific Pardot Business unit and can easily be shared across all of your Business Units. These components will enable your users to easily drag in standard areas of emails (copyright notice, unsubscribe language, etc.) as well as more technical components, making email building faster and easier. With no backend HTML access to Lightning Builder Email Content and Email Templates, custom components are vital to building advanced emails. 

What custom components do you plan on building? Let us know in the comments!

Original article: How to Develop Custom Lightning E-mail Components for Pardot

©2025 The Spot. All Rights Reserved.

The post How to Develop Custom Lightning E-mail Components for Pardot appeared first on The Spot.

The Pardot Winter’ 22 release includes a new way to add content to emails you create using the email content builder in Pardot Lightning. Custom components allow marketers to easily build a library of standardized components users can drag-and-drop into email content builder emails without needing to edit HTML or CSS. 

With this new feature, you can create components for standard areas of emails, such as footers or headers. Or, use it for more complex items, such as displaying upcoming events or gathering prospect feedback. 

You can create your own custom components, or search for components built by third parties in the Salesforce AppExchange. 

Pardot email custom components available now

Salesforce Labs already has three custom components available:

1. Embedded Feedback within Pardot Emails

Add a feedback form component to emails and gather instant feedback from prospects.

2. Video for Email

Easily embed video thumbnails.

3. Newsletter Lightning Email Template with Google API 

Create newsletter emails with components for Youtube Webinar and Google Calendar.

Once installed, the component will appear in the email content builder in Pardot Lightning under Custom. 

Note: You must be a Salesforce administrator or your Salesforce user must have the Download AppExchange Packages permission to install a custom component from the Salesforce AppExchange. 

Configure the custom component

Once you drag and drop a custom component into a Pardot email, you can use the right-hand side to configure the component. 

This new feature is available in the Lightning Email Builder for Email Content and Email Templates (Custom Components for Email Templates is part of the Spring ‘22 release). This feature is available for Growth, Plus, Advanced, and Premium Pardot editions.

Custom component availability

It is not yet available in the email template builder, but that should be coming in future releases. This feature is available for Growth, Plus, Advanced, and Premium Pardot editions.

Updating Pardot email content custom components

If a custom component is applied to email content and then that component is updated, the email content will not automatically reflect the changes. To update the email content, you must click Edit in Builder and re-apply the custom component. 

Considerations for multiple Pardot Business Units

If you have multiple Pardot Business Units, be mindful of creating custom components that reference fields, content, or assets that only exist in one business unit. Custom components are a platform asset and are not tied or restricted to a specific business unit. 

Share your experiences

How are you planning on using this new feature in your org? Tell us in the comments!

Original article: New Pardot Feature: Custom Components for Email Content

©2025 The Spot. All Rights Reserved.

The post New Pardot Feature: Custom Components for Email Content appeared first on The Spot.

In the Salesforce Winter ’22 release, Pardot launched the new drag-and-drop Landing Page builder, which allows users to create natively responsive landing pages and control when pages are published and/or removed. This builder uses the same integration as the drag-and-drop email content builder, so if you are already using that feature there is nothing new to set up!

This post will cover a few things you can do to ensure your users are successful with this new builder. For a great demo of this new feature, check out the Pardot Release Readiness Winter ’22 Webinar (The landing page builder demo starts around the 14-minute mark).

Note: We updated this post for the Salesforce Spring ’22 release.

Requirements and system usage

Before you get started with the landing page builder, you’ll need to ensure:

• The Pardot Lightning App is enabled (this new builder is only available in Lightning)
• HML is enabled
• Connected campaigns is enabled
• Salesforce CMS with My Domain is set up
• Users have the correct permissions to access the builder

You’ll also want to take a look at your landing page usage and limit. Landing pages published with the new drag-and-drop experience plus landing pages published with the classic experience will both count toward your account’s limit. 

To check your usage and limit, navigate to Pardot Settings > Usage and Limits

Ensure consistent use of naming conventions

Good naming conventions are going to be especially helpful when using this new builder. Naming conventions will allow users to quickly and easily locate the correct campaign, images, and form while building a new landing page. 

If you are using multiple Pardot Business Units (PBU) it will be even more important to have good naming conventions. When you create a new landing page, you will need to associate it with a connected campaign. The campaign you select determines which PBU the landing page belongs to as well as which forms can be used on this landing page (the landing page can only use Pardot forms that exist in the same PBU as the page). To make sure your users can determine which PBU a campaign or asset belongs to at a glance, I highly recommend adding your PBU name to the naming convention. 

To ensure naming conventions are used correctly on Salesforce Campaigns, check out our previous blog post on how to automate Salesforce Campaign Naming Conventions.

Vanity URLs

You’ll also want to make sure you have a good policy around using vanity URLs and ensure your users know how to check if a vanity URL is already in use before attempting to publish their new landing page. Vanity URLs are not validated until the landing page is published, meaning a team may center their marketing materials around the URL being www.sercante.com/really-cool-awesome-stuff only to find out upon publishing that this URL is already in use for another marketing initiative. More considerations for vanity URLs can be found here. 

Salesforce navigation and page layout edits

Make sure your users know where to find this new feature by adding the Landing Page tab to the Pardot Lightning App navigation.

1. Navigate to Setup >  App Manager
2. Locate the Pardot app (ensure the App Type says “Lightning”)

3. Select the dropdown arrow and click Edit
4. Select Navigation Items
5. Move Landing Pages over to the Selected Items pane, click Save

Also edit your Landing Page layouts to include the new Publication Details section:

You can edit this page layout by navigating to Setup > Object Manager > Landing Page > Page Layouts

Create new landing page list views

With more granular control over when Pardot Landing Pages are published and unpublished, as well as additional tracking of changes, creating a few list views will help you easily audit your pages. 

You can create new landing page list views by navigating to Landing Pages, clicking the Action wheel, and then New.

Configure a “Published Landing Page” view to keep an eye on metrics

• This view is filtered to only show “Status equals Published”

Configure a “In Progress Landing Pages” view to monitor which pages are unpublished but in progress:

• The “Content Last Saved” fields are updated anytime the landing page name, campaign, content, search engine indexing, vanity URL, Unpublish Redirect URL and/or Header and Footer Code are changed. Publishing and unpublishing a landing page does not update these fields.
• This view is filtered to only show “Status equals Draft”

Finally, configure a list view of landing pages that have a status of “Published (Changes Pending).” Unlike the classic landing page builder, new and updated pages will need to be pushed to “published” when they are complete. Landing pages will not auto-publish upon saving. This new change in functionality may cause some users to leave their page in the “Published (Changes Pending)” state and a list view can help you keep on eye out for these. 

For this list view, clone your “In Progress Landing Pages” view but change the filter to only show “Status equals Published (Changes Pending)”

Automate reminders to publish

Since users will need to publish landing pages when changes are made, you can set up a flow to remind landing page owners that their pages are not published. I set this up with a flow. My flow looks for landing pages with a status of “Published (Changes Pending)” and a Content Last Saved date of three days ago or less. My Flow will send an email reminder to the user who last updated the landing page for up to three days after their edits were made (unless the page is published). 

What excites you about the new Pardot Landing Page builder? Tell us in the comments!

Original article: How to be Successful with the Pardot Drag-and-Drop Landing Page Builder

©2025 The Spot. All Rights Reserved.

The post How to be Successful with the Pardot Drag-and-Drop Landing Page Builder appeared first on The Spot.

The Salesforce Winter ‘22 release made the Pardot Prospect Mailability upgrade permanent for all orgs. And it also introduced four new user abilities that allow for more control over which Pardot user roles can edit the new Prospect Mailability fields.

New Fields

1. Update Opted Out Field
   • Allows the user to edit the “Opted Out” field from the Prospect Overview page
   • Replaces “Toggle Opt-In Status” 
2. Update Do Not Email Field
   • Allows the user to edit the “Do Not Email” field from the Prospect Overview page
3. Reset soft bounce count
   • Allows the user to reset the soft bounce count for a prospect. When soft bounces are detected, a “reset” option will appear.
4. Reset hard bounce count
   • Allows the user to reset a hard bounce for a prospect. 

“Update Opted Out Field” will be enabled for the Pardot Administrator role by default. The other three abilities will be enabled for the Administrator role and the Marketing role by default. Users will only be able to manually toggle these abilities on and off within a Custom User Role. 

When should you reset soft and hard bounces?

You should reset a prospect’s soft or hard bounce if the bounce(s) only resulted from a system issue, such as:

1. The mailbox is temporarily unavailable or busy
2. The mailbox is full
3. An issue similar to when Barracuda incorrectly blocked vendor IPs including Pardot 

If the bounce(s) resulted from the email address not existing, the email or sender being blocked, or due to a bad sending reputation, you should not reset the bounce(s). Continuing to email prospects who have received a hard bounce for these reasons can have a severe impact on your send reputation! You can learn more about bounce codes and meanings here. 

What to watch out for

Removing a user role’s permission to “Update Do Not Email Field” and/or “Update Opted Out Field” only removes the ability to update these fields on the Prospect Overview page. Users will still be able to edit these fields via Automation Rules, Completion Actions, and Engagement Studio Programs. Due to this, I would highly recommend you read the “Ensure these new features are used correctly” section of our first Mailability Upgrade post as well as Lindsey Mark’s post about how to align your data after the upgrade.

What questions do you have about the new Mailability Upgrade? Tell us in the comments!

Original article: Preserving Prospect Email Preferences After the New Pardot Mailability Upgrade

©2025 The Spot. All Rights Reserved.

The post Preserving Prospect Email Preferences After the New Pardot Mailability Upgrade appeared first on The Spot.

Pardot announced some big prospect mailability changes in their Summer ‘21 release, and those changes are becoming permanent for everyone with the Winter ‘22 release. 

So, let’s break down exactly what’s changing, what your Pardot users need to know, and how to protect your prospects’ email preferences after this change. 

What’s changing?

Currently Pardot has two fields that control a prospect’s mailability:

Opted Out: Indicates the prospect has unsubscribed from marketing emails. Prospects who have opted out can still receive operational emails (a.k.a transactional emails) and autoresponders.

Do Not Email: Indicates the prospect cannot receive any email communications at all.

Things are about to get a lot more granular with the new prospect mailability changes. Pardot is adding a “Mailbility Insights” section to the prospect page with six fields:

1. Status: Outlines which kinds of emails prospects can receive and their overall mailable status.
2. Email Uniqueness: Records if the prospect’s email address has any duplicates in Pardot.
3. Opted Out: Indicates the prospect has unsubscribed from marketing emails. These prospects can still receive operational emails and autoresponders. 
4. Do Not Email: Indicates an internal user has suppressed this prospect from marketing emails. These prospects can still receive operational emails and autoresponders.
5. Soft Bounce Detected: Indicates the prospect’s email address has returned soft bounce(s) from an email send. A soft bounce occurs when an email is recognized by the recipient’s mail server but is returned to the sender because the recipient’s mailbox is full or the mail server is temporarily unavailable. Prospects with a soft bounce may be able to receive emails at a later time.
6. Hard Bounce Detected: Indicates the prospect’s email address has returned hard bounces from an email send. A hard bounce occurs when the prospect’s email address is invalid, the domain name does not exist, or the sender is suspected as spam and/or has been blocked. Prospects with a hard bounce are no longer mailable. 

Previously when a prospect was marked as Opted Out, the Do Not Email field would also change to “TRUE.” This is no longer the case with the new update. 

This change also enables a new filter to view Undeliverable Prospects (a.k.a prospects who  have received a hard bounce or 5 soft bounces).

More changes to note

• If you upgrade to the new mailability insights early, all Pardot users will have access to update prospect Opted Out and Do Not Email fields. The Pardot user role permission “Toggle Opt-In Status” will no longer restrict access to the Opted Out field. However, this is changing with the Winter ’22 release. In the release, the “Toggle Opt-In Status” field will become “Update Opted-Out Field” and, if set to TRUE, allows a user to edit Opted Out on a prospect record.
  
• Overwrite Prospect Opt Out Field is enabled by default.
  
• A prospect’s number of soft bounces can be reset (remember 5 soft bounces equal a hard bounce).
  
  
• Pardot will mark a prospect with a hard bounce as “Undeliverable.” But, it will no longer automatically change their Do Not Email field to TRUE.
  
• The only way to resolve a prospect’s hard bounce status is to change their email address to an address that does not have a hard bounce.

New prospect mailability capabilities

The prospect mailability upgrade also includes new ways to edit, update, and use the prospect mailability fields. You can edit or manually query these fields on the prospect page through an import or via automation rules, dynamic lists, completion actions, and Engagement Studio programs.

Ensure these new features are used correctly

With great power comes great responsibility. So, work with your users to ensure everyone understands the new mailability updates and when or when not to change a prospect’s status. 

I recommend that you:

• Review your Pardot user roles to determine which user roles have access to change the Opted Out and Do Not Email fields. You’ll want to look for the access to create/edit:
  1. Automation Rules
  2. Page Actions
  3. Custom Redirects
  4. Files
  5. Emails
  6. Forms 
  7. Form Handlers
  8. Engagement Studio Programs
  9. Prospects
     You can learn about the permissions for the four default user roles here.
     
• Train your users on bounce codes and outline which codes can be resolved and which cannot. Make sure you avoid re-contacting email addresses that will never be successful. Contacting those addresses can have a severe impact on your send reputation!
• Read Lindsey Mark’s post about how to align your data after the upgrade. 

How should you use these new fields?

Here are a few tips that should help you navigate through the new features.

• Mark incoming prospects as “Do Not Email” until they have explicitly subscribed to your marketing materials. This will allow you to track, score, and grade the prospect while still respecting their email preferences. 
• Regularly review your soft and hard bounce error codes by creating dynamic lists of prospects with errors.
• Edit (or create) your double opt-in process to ensure prospects who subscribed but have not yet confirmed their email address are marked only as Do Not Email. 

How do you plan on using Pardot’s new Mailability upgrade? Let us know in the comments!

Original article: Are You Ready for the Pardot Prospect Mailability Upgrade?

©2025 The Spot. All Rights Reserved.

The post Are You Ready for the Pardot Prospect Mailability Upgrade? appeared first on The Spot.

One of the newest additions to the Sercante team, Skyler Nakashima, recently wrote an awesome post on How Pardot’s New Handlebars Merge Language Improves Personalization.

Spoiler alert: it’s exciting stuff. (And not just because of the artsy bike photography I’m collecting to use in future blogs.)

If you’re sold on the perks of HML and ready to get started, then read on about how to turn this on for your org!

Pardot’s New Handlebars Merge Language (HML) was rolled out in the August 2019 release. It is now available in all Pardot accounts as a feature that can optionally be activated. Here’s the blow-by-blow on how to get rocking and rolling with this new resource.

Update from Salesforce:

“As of June 12, 2020, Handlebars Merge Language is on by default for all new Pardot accounts. For accounts where it is not yet enabled, Pardot admins can permanently upgrade from Pardot Merge Language (PML) to Handlebars Merge Language (HML) for personalizing Pardot marketing assets.”

1. Go Ahead… Click the Big Green Button.

To get started, click the magic green button on your Pardot dashboard:

2. Read the “Point of No Return” Disclaimer and Get Nervous.

Once this feature is activated, it can’t be turned off. So you’ll get the obligatory “whoa, partner” warning:

The verbiage on these feature activation windows always gives me the chills. Suddenly the blue button seems so intimidating.

Thank the Pargods for the Tell Me More link….

3. Determine if You’re a Fit by Reading the FAQ

Future Pardot functionality will be built around HML going forward. In general, with new features like this we recommend adopting them early unless there is a major red flag or reason not to.

There are only two use cases that Pardot has identified as requiring some caution:

If you use variable tags in dynamic content on Pardot forms or landing pages, we recommend you do not upgrade at this time.

The Pardot API supports both PML and HML for list emails and 1:1 email sends. If you or a third-party uses API functionality, look into any changes you may need to make before you upgrade.

4. Understand the Upgrade Path for Old Assets

The term for the “old way” is PML — Pardot Merge Language (PML). Aka the %%stuff%% from variable tags and dynamic content.

You won’t be forced to update any of your PML content in old assets, at least for now. Your content will remain untouched by the upgrade, and you can still edit using variable tags / PML. Dynamic content blocks that contain PML tags can still be used in all new and existing emails.

When you copy or edit a PML asset, a conversion wizard will walk you through converting all your PML tags to HML. According to Pardot:

Each asset can be converted individually when you’re ready to use it. All you have to do to convert is click a button, and we take care of the rest. If any issues arise, the conversion tool tells you what needs attention.

If active Engagement Studio programs, completion actions, and automation rules use old PML templates, no problemo — these will continue to work as they always have, and you can convert your PML templates when you’re ready.

5. Get Ready to Start Using HML for New Assets

When you activate HML, you will have to create all new assets of these types using HML:

• List emails
• 1:1 emails
• Email templates
• Dynamic content blocks
• User signatures

HML is not yet available in forms and landing pages. In the meantime, you can still use PML.

Pardot has published a number of help articles to help admins get familiar with the new Handlebars Merge Language use and syntax. (From what I’ve seen, though, the “merge picker” makes this pretty straightforward to use so I wouldn’t worry about knowing every detail backwards and forward before activating this feature.)

6. Consider Activating in a Training Environment First

As a best practice, I recommend enabling shiny objects in your Pardot training environment first. This upgrade path is fairly simple, but even so, give it a practice run outside of production.

7. PULL THE TRIGGER!

If you’ve reviewed this blog and Pardot’s documentation… and you’re ready to rock…. then hold your breath and click that magic button:

8. Sigh in Relief & Commence Happy Dance

Once you click the button, you’ll see a confirmation at the top of your screen:

Okay, it’s kind of anti-climatic.

But it’s really that simple!

What This Looks Like in Your Org After Activation

HML in New Templates

When you go to create new emails using Pardot default templates, you’ll see HML in the place of the old variable tags, for example:

HML in the Email Editor

In your email editor you’ll see a familiar looking “merge field” button:

HML in the “Merge Picker” (aka Actually Trying to Use it in Templates)

Clicking the “merge field” button launches the updated “merge picker” which streamlines the process for inserting HML:

HML When You’re Doing it Wrong

Another comforting thing to note: Pardot won’t let you save an email if your HML conditional formatting contains an error or isn’t closed, and itwill let you know what to fix.

Here’s an example of the kind of errors you would see if trying to save HML that’s incorrectly formatted:

HML When You’re Using & Viewing Old Assets

When you go to view existing email templates and assets, you’ll see a little pop up like this:

And on attempt to edit an old template, you’ll get a note about converting to the new HML format:

Click got it, and you’ll get confirmation that your PML was converted for you:

Are You Ready for Pardot’s Handlebars Merge Language?

Overall, I have to say I’m super impressed with the ease of use and UX of the upgrade path to HML. Can’t wait to start putting this to use!

There are lots of exciting use cases made possible by HML, and this is just the tip of the iceberg. Word on the street is that this merge language is the foundation of future efforts to insert merge fields from opportunities, customer objects, and more. And since this is the exact same language used in Lightning templates, this brings Pardot and Salesforce one step even closer together.

Have you started working with HML yet? What are you learning? Any surprises or things you’re eagerly anticipating in future releases?

Let’s hear it in the comments!

Original article: How to Enable Pardot’s New Handlebars Merge Language (HML)

©2025 The Spot. All Rights Reserved.

The post How to Enable Pardot’s New Handlebars Merge Language (HML) appeared first on The Spot.