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.

Marketo v. Pardot Cage Match: Round 2, Sending Emails

Edited to include a note on Marketo’s Email Editor v2.0

First of all, disclaimer: Marketing Automation is not just for email automation. It does a lot more than that. However, for a small team that is just starting out with Marketing Automation, this is likely where you’re going to start, so that’s where we are now.

It also is something that should be considered as part of any and all marketing initiatives. It’s easy to think that “email marketing” and “sending emails via Marketing Automation” are the same thing, but they are not.

Email marketing is a channel of marketing.

Sending emails is the ability to send an email to a prospect – be that via email marketing, specifically, transactional emails, drip campaigns, or even internal messaging.

Now that that’s out of the way, here’s how I’m breaking down this round of the cage match:

  1. Planning: this involves the process of planning what and when to send
  2. Designing: this involves the ease of creating the email – can you clone something you’ve built, how do templates work, etc.
  3. Sending: this is pretty straightforward. How easy is it to send the thing you’ve planned and created?
  4. What I am NOT covering: Dynamic content in emails – I will be handling things like this in another post.

These are exceptionally broad-stroke sections, I realize. A lot goes into planning. But since every team does planning just a little bit differently, I don’t want to get into the nitty-gritty here. I’ll give examples, though, don’t worry about that.

Continue reading “Marketo v. Pardot Cage Match: Round 2, Sending Emails”

Sales Cloud for Marketing 2: Programs to Campaigns

Welcome to part 1 of my “Sales Cloud for Marketing” series, where I will discuss how to force Marketing and Sales to work together to make data that we can use.

Today’s topic: building Marketo programs that play nice with Salesforce.

To start off, let’s make sure we get the nomenclature down. In Marketo, a program is a collection of things, essentially, that all come together to send/share/receive information with people, be they potential prospects or existing clients. When I speak to the marketing team, I generally tell them that, at a high level, a program is what we might more traditionally consider a campaign.

In Salesforce, they are still called campaigns.

To be 100% honest, I don’t know why Marketo chose to call them programs, I really don’t. I’ve searched, but I’ve never gotten a clear answer. I can’t imagine it was a trademark issue…

Anyway, point is, when you think of a marketing campaign – a coordinated set of steps that are used to promote a product or service – think “program.”

First thing’s first…

You’re going to need to ensure that your channel setup makes sense in both Marketo and Salesforce. For programs that you’ll want Salesforce users to assign contacts or leads to (or report on, for that matter), you’ll want to consider what statuses people can be assigned.

For instance, if you’re hosting an event and would like sales to track members in Salesforce, they might need to know if the prospect has been sent an invite, opened an invite, clicked a registration link on the invite, etc.


Channel list, where you’ll control what channels you can assign to programs

You’ll control these statuses in Marketo’s Admin section, via Tags. Marketo provides a tag called Channel, where you can change different statuses, based on the channel of marketing. Your email channels might have “open” and “clicked,” whereas a webinar channel might include “registered” and “attended.” Make sure you consider what marketing and sales would need to know for each channel.

Onto the Program

This is definitely a preference thing, but we have consistent naming conventions in Marketo for our programs, and I love consistency for reporting. Accordingly, I create programs in Marketo and sync them to new Salesforce Campaigns.

If you want to have different names in Marketo and Salesforce, that’s fine – it’s just going to add a step here.

Under the Summary view of a Program, you can sync to a Salesforce Campaign

Assuming you want to do it my way, all you need do is create the program in Marketo, then go to its Summary page. Under settings you’ll see the Channel (which you cannot change), created and last edited information, and “Salesforce Campaign Sync,” which will be unset. If you click on “not set,” a popup screen will appear, from which you can select “Create New” from a drop down. And voila – you now have a Salesforce Campaign that will sync with your Marketo program.

Channel list, where you’ll control what channels you can assign to programs

If you want to use different names, you’ll need to create the Campaign in Salesforce and instead of selecting “Create New,” find the one that you’ve previously created.

A word of caution: If you have a lead scoring process, don’t sync any campaigns that could provide new names. This sync will overrule your lead scoring and sync the new names to Salesforce once they’re added, regardless of score.

Congratulations! You’ve created a Marketo program that will now speak directly to a Campaign in Salesforce! If your OWDs in Salesforce allow it, your SFDC users will now be able to track a person’s movement through a Program/Campaign.

Next up: Campaigns from Programs (this time, it’s Salesforce)

See Part 2

See Part 3

Sales Cloud for Marketing 1: Intro

I’ve had my fun, talking about myself, letting my freak flag fly, etc. But now it’s down to brass tax and all that. No one starts a Salesforce blog just to see their words on the screen (I  mean, that’s part of it) – they do it to give back to the community that offers them so much.

I’m no expert (obviously), but like most solo admins out there, I have a unique situation that has given me some insight that others might not have. You see, technically I work for my marketing team. I am the “Marketing Data and Systems Analyst,” which is totally cool, but it doesn’t accurately reflect what I do.

In reality, I support Marketing, Sales, Account Management (Client Services), and pretty soon, Customer Support potentially. I also help out our training team and our implementation team sometimes. I work with Finance. And sometimes I rub elbows with IT.

But technically I’m in marketing.

The bulk of my data analysis needs to be for both Marketing and Sales, which means most of my data management must balance both teams’ needs, as well. If I were to romanticize what I do, I’d say that I find ways to bridge the data gap between Sales and Marketing. In reality, I just have two cats that I’m constantly trying to herd into one place without them hissing territorially.

There are a few ways I’ve worked this out, and I intend to share them. For the record, my solutions thus far have depended on the following:

  1. We use the Enterprise version of SFDC, Sales Cloud only (so far)
  2. We are on the SMB-Select edition of Marketo

To keep things relatively short, I’m going to break this information out into a couple of posts to make a series, the Sales Cloud for Marketing series to be precise.

I’m going to cover a few things that I’ve learned herding these cats.

My first post in the series will be Marketo-heavy, and it will talk about some best practices on building Programs that will sync nicely with Salesforce. Those of you that use other marketing automation tools, the following part might be more applicable, and it will be making the case for making most, if not all, SFDC users “Marketing Users.”

I look forward to sharing this journey with you!