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
| Scenario | Result |
| Submitted by new person | New Lead Created |
| Submitted by existing lead | New Lead Created |
| Submitted by existing contact | New Lead Created |
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
| Scenario | Result |
| Submitted by new person | New Lead Created |
| Submitted by existing lead | Existing Lead Updated |
| Submitted by existing contact | New Lead Created |
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!
