Considerations for Using Form Handlers
Before using form handlers, keep these considerations in mind.
Required Editions
| Available in: All Account Engagement Editions |
General Considerations
- We recommend that you implement bot protection on your forms when using form handlers. Otherwise, you could be complicit in subscription bombing. Talk to your IT team to implement a CAPTCHA or IP blocking, or consider implementing a confirmed opt-in process for your form handler prospects.
- As a best practice, set the email address field on your form to required.
- Form handlers can do browser-side posts (the usual posting method) or server-side posts. For server-side posts, enable Kiosk/Data Entry Mode on the form handler to prevent tracking your server as the prospect. Server-side posts record the form handler submission activity on the prospect’s record, but don’t have a tracking cookie.
- Conditional fields aren’t available on form handlers because they don’t work on external content.
- Form handlers integrate with forms using an empty enctype attribute or an enctype of application/x-www-form-urlencoded. Form handlers don’t accept multipart/form-data.
Referrers and Errors
- More stringent security policies strip referrer IDs from submitted form handlers. To make
sure redirects work as expected, add this snippet of HTML between the
<head>tags of any web page that references a form handler.<meta name="referrer" content="no-referrer-when-downgrade" /> - If a field is required on your form handler, make the field required on your form. Otherwise, the form submission fails when a prospect leaves the field blank.
- When prospects don’t complete a required form field, they’re redirected to the error location with some messaging appended as parameters to the error location URL. Either a server-side process or JavaScript can read the parameters and use them to display an error message to the prospect. We suggest editing your form field error messages to include details that identify the field producing the error.
- If you delete a form handler, delete or update the associated form from your site. If you leave a form integrated with a deleted form handler, prospects receive an error message on submission.
- Form handlers accept “success_location” and “error_location” as URL parameters on POST, which override the form handler’s stored success or error location settings. These parameters don’t overwrite values already recorded in Account Engagement. Those values are temporary parameters that apply only to that specific POST request. The parameters must be URL-encoded and valid URLs that match your root tracker domain or go.pardot.com. Otherwise, the form handler redirects to the referring page. For example, a custom tracker domain of www2.mycustomdomain.com and a success location of go.mycustomdomain.com work since the root domain of mycustomdomain.com matches.
Considerations for Accounts That Allow Multiple Prospects with the Same Email Address
- Form handler submissions made online and in Kiosk mode are related with a prospect based on an email address. If there are multiple matching email addresses, the submission is associated with the prospect with the most recent Last Activity field value. If the prospect with the most recent Last Activity field value is in the Recycle Bin, it’s undeleted. If there are no matches, a prospect record is created.
- If a cookied prospect submits a form handler with new information, the prospect record associated with the cookie is updated.
- If a cookied prospect changes the email address on a form handler, we create an additional prospect record.
Did this article solve your issue?
Let us know so we can improve!
