Best Practices for Submitting Forms in Salesforce Marketing Cloud
I have seen many blogs written on this topic, but almost all of them got it wrong! Even the major players in the SFMC world—whom we rely on for our answers—were not using any best practices there are when submitting a form. I will show you a better way to submit a form and highlight the basic issues I’ve encountered in form submission blogs.
In case you want to listen to the content, try the AI narrated blog post:
How not to submit a form in Salesforce marketing cloud
If it works, don’t touch it” is the simple rule, but after seeing the same cringy issues repeatedly, it’s time to give the internet new and somewhat at least to me “basic” form submission using bit of good practice.
Single-Page Form Submission Handler
Let’s take a look at the following example of how not to submit form in any platform ever:
%%[IF RequestParameter("submit") AND RequestParameter("email") THEN
InsertData("leadCloudPage","email", RequestParameter("email"))
]%%
<p>Thank you for your submission!</p>
%%[ELSE]%%
<form action="https://www.example.com" method="post">
<label for="email">Email:</label>
<input type="email" id="email" name="email" placeholder="Enter your email" required>
<input type="hidden" name="submit" value="ok">
<button type="submit">Submit</button>
</form>
%%[ENDIF]%%Do you see any problems? I’m not referring to the validation—that’s not the point I’m trying to make here.
Assuming everything is working fine, let me explain why you shouldn’t submit forms this way. The main issue is that the form can be submitted using a GET request. This means you don’t even need to fill out the form—you can simply enter the form URL, append GET parameters, hit refresh, and flood someone’s Data Extension without even using a any form of submission automation. When you submit the form by pressing F5 – page refresh we introduce unwanted duplicates and more processing on our end later.
Multi-Page Form Submission Handler
In another example done differently fixing one of the issue but one still present. We split our form submission logic into form page where our form is and processing form page where user data lands after the form is submitted and are processed.
Form page
Simple form (no front end validation)
%%[IF RequestParameter("ok") THEN]%%
<p>Thank you for your submission!</p>
%%[ELSE]%%
<form action="https://www.form-submit.com" method="post">
<label for="email">Email:</label>
<input type="email" id="email" name="email" placeholder="Enter your email" required>
<input type="hidden" name="submit" value="ok">
<button type="submit">Submit</button>
</form>
%%[ENDIF]%%Form processing page
Processing form page where we simply try to insert data coming from our form
%%[IF RequestParameter("email") THEN
SET @formPage
InsertData("leadCloudPage","email", RequestParameter("email"))
Redirect(@formPage,"?ok=1"))
]%%Here, we see the same problem: not checking the HTTP request type. Why even bother? Let me finally explain the issues you may encounter if you don’t change your form submission approach. This allows someone to directly ping your form processing page (‘form-submit.com’) with appended query parameters, causing the form to submit.
If you want your lead form to be taken over by spam—even if you’re using form validation and bot detection software—please leave me a comment with you lead form URL so I can flood the living live out of your marketing instance. (joking I am good guy)
If you want to adhere to the basics (at least for me but I think many would agree) of form submission, read further and of course improve on what you will read next
How to submit a form in salesforce marketing cloud
First of all, let’s tackle HTTP request type check, as we do not want users to submit the form by simply pinging the URL with added query parameters. This can be solved with a bit of SSJS using the platform’s native functions.
Submit marketing cloud page form with HTTP request type check
<script runat=server>
Platform.Load("Core", "1.1.1");
//Variable.SetValue('@ip', Platform.Request.ClientIP); to give you more ideas :P
Variable.SetValue('@request', Platform.Request.Method);
</script>
%%[
SET @errorPage = 1111
SET @thankYouPage = 2222
SET @error = false
IF @request=="POST" THEN
SET @email = RequestParameter("email")
/*raise error when email is empty*/
IF EMPTY(@email) THEN Redirect(CloudPagesURL(@errorPage,'message','email should not be empty')) ENDIF
]%%
<script runat=server>
try{
</script>
InsertData("leadCloudPage","email", @email)
<script runat=server>
}catch(e){
Variable.SetValue("@error", true);
InsertDe("leadFormErrorLog","message","Error inserting to DE: " - Platform.Function.Stringify(e)))
}
</script>
IF @error == true THEN Redirect(CloudPagesURL(@errorPage,'message','Error while saving lead')) ENDIF
/* success redirect to thank you page */
Redirect(CloudPagesURL(@thankYouPage))
ENDIF
]%%<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Basic form submission</title>
<style>
.error-message {
color: #721c24;
background-color: #f8d7da;
border: 1px solid #f5c6cb;
padding: 10px;
border-radius: 5px;
margin-bottom: 15px;
display: none;
}
.visible {
display: block;
}
</style>
</head>
<form action="%%=RequestParameter('PAGEURL')=%%" method="post">
<label for="email">Email:</label>
<input type="email" id="email" name="email" placeholder="Enter your email" required>
<div id="errorMessage" class="error-message">
Please enter a valid email address.
</div>
<button type="submit">Submit</button>
</form>
<script>
document.getElementById('myForm').addEventListener('submit', function(e) {
const email = document.getElementById('email').value.trim();
const errorMessage = document.getElementById('errorMessage');
// Simple email regex for validation
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)) {
errorMessage.classList.add('visible');
e.preventDefault(); // Prevent form submission
} else {
errorMessage.classList.remove('visible');
}
});
</script>Lines 1-3 (Getting HTTP request method)
The script stores the HTTP request method (GET or POST) in the @request variable using Platform.Request.Method.
Line 7 (Checking Request Method)
This conditional block checks if the request method is POST (IF @request=="POST" THEN). This ensures that form processing only happens on a form submission and prevents processing on a simple page visit (GET request).
Line 8 (Retrieving Form Data)
The script retrieves the submitted email value using RequestParameter("email"), storing it in the @email variable.
Lines 9-10 (Handling Missing Email)
This block checks if the @email value is empty. If so, the user is redirected to the error page (@errorPage) with an error message ('email should not be empty'). This prevents form submission with an empty email field.
Lines 11-12 (Starting Try-Catch Block in SSJS)
A try-catch block is initiated in Server-Side JavaScript (SSJS) to handle potential errors when inserting data into the Data Extension (DE). The function throws an error when you try to insert data into a non-existent column or if you miss required columns. However, I recently learned that even a try-catch block won’t help when inserting into a non-existent column.
Lines 14-17 (Handling Errors in Data Insertion)
If an error occurs during data insertion:
@erroris set to true usingVariable.SetValue("@error", true).- The error details are logged in another Data Extension (
leadFormErrorLog) with the message"Error inserting to DE: "followed by the error details (Platform.Function.Stringify(e)). - This ensures errors are tracked instead of showing a generic 500 Internal Server Error to the user.
Lines 18-19 (Redirect to error page)
If @error is true, the script redirects the user to the error page (@errorPage) with a message "Error while saving lead". This prevents them from seeing an unexpected system failure.
You may ask yourself why I set @error and redirect only after the catch block. The simple answer is that Marketing Cloud cannot handle the redirect function within a catch block.
Lines 20-21 (Successful Submission Redirect)
If no errors occur, the script redirects the user to the thank-you page (@thankYouPage), ensuring a smooth user experience.
What has improved by submitting form with request type check?
This is a better way to process your form submissions, here is the pain points we have improved:
- The form won’t submit on a GET request. In lines 1-5, we retrieve the request type, and in line 11, we ensure that only a POST request will trigger the form processing.
- Added a redirect after a successful submission to prevent users from pressing refresh and resubmitting the form.
- Added client side and server side form validation.
- Added error-handling logic in case there is an error in saving data to the Data Extension, preventing the user from seeing an internal server error page.
What can be improved in our form submitting with request type check?
There are thing that can be improved for sure and bring this form into the perfection. Here are some that I can quickly think of:
- we can try using SSJS execution context that the code inside only triggers when cloud page is accessed via POST request. The need to check request type will be obsolete.
<script runat="server" language="JavaScript" executioncontexttype="Post" executioncontextname="test" > [Add your SSJS code here] </script>
- We can use CSS frameworks such as bootstrap to improve our client side validation
- We can improve server-side validation to return all invalid fields along with the data already submitted, ensuring the form is prepopulated.
How to add additional security to your marketing cloud page form?
We can add reCAPTCHA to make sure no spam will get through. If we want to prevent page from being public we can introduce authentication using IP whitelisting, simple login etc..
