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.

Untitled Diagram.jpg

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:

Screen Shot 2020-01-06 at 10.12.22 AM

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.

Travel as a metaphor

I got back into Michigan from New York on Saturday afternoon, only about 13 hours after my originally scheduled time. Other at Arkus were far more delayed than I.

It was all of the storms – crazy thunderstorms and a few tornado watches all along the Eastern coast that had flights coming in cancelled, which means no planes to carry us all home. I was holed up in the Delta Sky Lounge, courtesy of Coworker, when my phone buzzed with the cancellation notice.

Cut to about an hour in line, with a lot of other tired non-passengers, hoping to get something other than a three leg journey through Syracuse, then Atlanta, and then home just shy of Sunday morning.

These kinds of things are exhausting and anxiety-inducing to me, but they’re not something that makes me mad. The poor saps behind the counter can’t do anything about Mother Nature’s wrath against her ignorant children, so I’m not about to scream at them.

“If weather could be controlled, Delta would have bought it by now,” was my favorite line from the helpful attendant who patiently refreshed his screen to see if he could get me to Atlanta (impromptu family visit?) or Minneapolis (daily flights back to Michigan).

The wait (and my volunteering to sort some info cards for them while I did so) was worth it. I got on a flight to Minneapolis that night, stayed with Coworker for free, and hopped back on a plane the next morning to come home. Cue celebratory Electric Hero sandwiches, cocktails, and blessed sleep.

Travel, man, am I right?

Sam, you haven’t posted in months, and now you’re going on about travel, and you mentioned a metaphor, but…?

Allow me to use your question as a convenient transition and take you back in time about 4 months.

Another Coworker made the decision to move on to other things after some life changes, and so I took on a few extra projects that needed to be closed out. I also got a promotion – not sure I’ve mentioned that? Anyway, yeah. So I had the experience of onboarding an employee.

Things were kind of crazy. A lot of pressure systems moving around, as you can imagine, and accordingly, a lot of things were delayed, some things were cancelled. But during that time I learned a lot – got hands on with some new things, got creative with some other things, and also just did a lot of work.

Skies have cleared. I got a lot of things off my plate, and not a moment too soon, as we enter Dreamforce season (already?) and very soon after that, holiday season. I still have some behemoths hanging around, major projects that are ramping up, but it’s so good to just breathe. I feel in control again – finally, after months of feeling like I was on a loop, digging and digging and digging but never seeing the surface.

And isn’t that the thing that’s so frustrating about travel issues?

 

 

Time flies etc.

I have had a few people lately approach me to ask about what it’s like being a consultant. I’m always a little surprised by that because I think “why would they ask me? I haven’t been at it very long.”

I looked at the calendar recently. It’s already almost September. 2017. What the actual…anyway, that means that I’ve been a consultant for over a year now. And being the annoyingly introspective person that I am, that led me to hours and hours of thinking about that question and my answer.

I still don’t feel like I’m the right person to ask. There are still days where I haven’t quite gotten my feet underneath me. The treadmill is still just a tad too fast sometimes, and I stumble. Being human means that I focus a lot on those stumbles and less on the increasing number of successful steps.

Here’s how I’ve been answering that question.

Becoming a consultant is like any other major change in life. Day to day, nothing changes. I get emails from clients – sometimes I know the answer off-hand, and sometimes I have to do some research. I build things in Salesforce, and then I test those things and rebuild them. I provide insight into what the platform can and cannot do, what it can do natively vs. custom, what might be better left to a third party app, etc. I encourage admins to learn, and somewhere in all of that, I manage to occasionally put on a virtual meeting for the West Michigan WIT group.

But then I look back over the past 3 months, and I realize I have learned quite a bit. Over the past 6 months, 9 months…a year. I see things that I did early on that I would do differently now. Not that I was wrong then, but I’d be better prepared for them now.

There are little things, too. I speak more confidently about some things than I used to. I recognize patterns that I hadn’t noticed before. Gradually, I’m getting faster with some things.

Even I keep waiting for something to click. Some obvious and clear sign that says “You are now a Consultant.” But that’s not going to come. My business cards and job description say that. What I do on a daily basis says that.

That’s been the biggest lesson for me. I’ve learned in every job I’ve ever had – that’s what we do. This time it just feels more intangible. I can’t say “I now know how to complete an OSHA 300 and 300A form.” It’s more things like…”I now know that I can use Talend for data transfers and transformations.” But that encompasses so many things, not just a single task or ability.

As one of the least patient people I know, this kind of slow adaptation and realization of what I’ve learned has been both the most difficult and most rewarding part of the transition for me.

I don’t know if that’s the kind of answer people are looking for when they ask. Being a consultant varies depending on where you work, on what kind of team you’re working with. Just like being an admin at one place will be different than being an admin at another. But that’s the best answer I can give.

Regardless I’ve appreciated the questions because they forced me to take that long look and give myself some credit for how far I’ve come. And it’s made me really excited for whatever will come next. What will I know 3 months from now? 6 months, 9 months, a year?

If nothing else, I can safely say that being a consultant is never dull, and that’s probably the most important advice I can offer.