What I learned this week about: Pardot Form Handlers

A better title: What I learned last year about Form Handlers and am now getting around to posting. Holidays, amirite?

I could probably write a whole series on Pardot Forms and Form Handlers, but it’s also probably been done already. Plus there is documentation available. Or you could pop over to Jenna Molby’s blog for a lot of great content in that same arena.

I’m here today to get into some of the things that you really need to know and consider upfront because here’s how a lot of conversations about form handlers go:

Me: Pardot has forms, which are fully functional, hosted on your Pardot instance, and can take some custom styling, and it has form handlers, which allow you to identify the fields that you want to accept data for, and then Pardot generates a post-to URL.

You: So there’s really no difference?

Me: No, there is a big difference. One is a form. One is a post-to URL, so ANOTHER form can send data to that handler, and then the handler disperses the info to Pardot.

You: So form handlers are better for forms that have custom formatting?

Me: They CAN be, but I tend to think of it as – ‘I have a longer, more complex form, and I only need SOME of the data to go to Pardot.’

You: But they can do all the same things, right?

Me: No. Because the form handler is just a post-to URL.

You: I get it. We want to do a form handler, then. Our web developer will create the form.

Fast forward a few weeks, maybe even months, and when troubleshooting happens, everyone is confused. Here are the reasons why and what you should know BEFOREHAND.

Troubleshooting a form handler takes place in two (or more) places.

Scenario: We have a form on a website that is accepting four fields, and some of those fields are not appearing in Pardot.

What you need to check:

• The fields identified for your form handler
• The data type of the field on your form
• The data type of the field defined in your form handler
• The data type of the field in Pardot accepting the data
• The field name on your form
• The field name defined in your form handler

If ANY OF THOSE are out of sync (as in not exactly the same), then you will not get data in that field.

When you bring Salesforce into the mix, it can become even more complicated, as you now need to consider your data formatting from form, to form handler, to Pardot Prospect field, to Salesforce field.

You have basically ZERO (0) options for form handlers.

Want a custom error message? You have to create it on your site.

Want progressive profiling? You have to create it on your site. (Oh, and you have a required field on your handler? Then guess what has to be on EVERY VERSION of that custom built form.)

Want to control accepted data values, like for a dropdown menu? You have to enforce that on your site.

Here’s what you can control with your Form Handler:

• What fields will accept data from your form
  • What format that data should be in
  • What the name of that field is on the form itself
  • Is this data required?
• A success location (where the form redirects on a successful submission)
• An error location (where the form redirects if there is an error – but see note #1 above)

That’s basically it. If you want to change something, ask yourself – is it one of those three things above? No? Then it needs to be changed on your site.

The ONLY THING a form handler does is generate a post-to URL and then disperse data to Pardot fields.

Oh yeah – you should know what a post-to URL is.

To understand what Pardot is actually doing, you need to understand the two basic functions of an integration (like SUPER BASIC functions) – you can GET data FROM a place, or you can POST data TO a place.

With a form handler, we are essentially building half of an integration. We have a custom HTML (probably) form that we’ve dropped onto our website, and that form does All The Things. It controls the look and feel, what questions show up, the format of those questions, etc.

When someone clicks on that submit button, Stuff happens. One of the Stuffs that can happen is a POST method (a command that tells the form to send data to a place). When we POST, we have to tell the form WHERE to post. And we can do that via a URL.

Pardot provides that custom URL for us when we create a form handler. When the data is submitted, the data types that we defined, and whether or not a field is required, is reviewed, and a success or error message is sent back to the originating source. And of course the data that is accepted is then entered to a Pardot Prospect, based on the field mapping we provided.

Speaking of fields…you should also know that

• checkboxes are not going to work the way you think they will
• date fields in Pardot use a different format than Salesforce date fields
• you cannot add custom validation to the fields on the form handler (see section 2)

Checkboxes are the big one here.

What you expect: When I check a box, that means that the Thing is True.

What Pardot understands: Nothing. It understands nothing.

This is what adding a checkbox to your form handler looks like:

Do you see a place for checkbox? Boolean? NOPE.

Guess where you can control what actually gets passed to your form handler? 100 points if your answer was “on the form itself on the site” or similar.

I’ll just write a whole other post about checkboxes in Pardot, actually, so stay tuned.

They aren’t inherently evil, but…

I am not here to just bash form handlers. They can be a useful tool, but it is worth mentioning that they come with additional complexity that assumes a certain level of comfort with some technical concepts – HTML, CSS, HTML methods, etc. They are not for the faint of heart, and they are not a good substitute for true forms.

So when do I recommend using them, for reals?

• If you have a very long, custom form, and you want SOME of that data to go to Pardot AND the data is very simple
• If you have very strict requirements for customization that a standard Pardot form cannot guarantee (this is unlikely, but you never know)
• If you already have a form and just need to send the data to Pardot AND the data is very simple
• You have a form tool like Form Assembly that has a pre-built integration and are figuring “WHY NOT?”

That’s pretty much it. And that last one even is meh.

A final note/rant on this stuff

Pardot forms (and handlers) are NOT meant to be a full form solution. You should not be using either of these options for things like applications. Think of a Pardot form/handler as a handshake. What is the most basic information you need from a person to get to know them? What is a FAIR exchange of information with your prospects at the lowest level?

If you keep that in mind, forms and handlers are much easier to deal with.

As always it’s about the right tool for the job. Just make sure you know exactly what you’re doing before you pick up a form handler.