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.

What I learned this week about: Pardot Responsive Layouts

I built my first responsive email template in 2014 when I was just coming into the MOPs/Salesforce Admin portion of our programming and realized that my company’s marketing emails were NOT responsive.

Me being me, I ended up sitting through a free webinar put on by Litmus to gain the basic understanding of how responsive emails worked, and from there I was the go-to on the team for all things HTML and CSS. I fumbled my way through enough to ensure that our emails and custom landing pages would look good on mobile.

Side note: I did all of this because I had reviewed the open rates based on device and found that approximately 30-40% of our emails were being opened on mobile. That’s a pretty sizable chunk of people having to squint at tiny print on a small screen.

I am not an expert on this stuff at all, so I’m not about to sit here and break down how to do this – there are much better resources out there for that. All you need to really understand about this is that responsive emails are based on tables, as in:

<table>

<tr><td></td></tr>

</table>

That at least I understood having been big into building strangely elaborate personal webpages when in school. I wish I had screenshots of some of the work I did back then – it wasn’t terrible, all things considered.

For responsive emails these are important because you end up with nested tables – tables inside of table cells inside of tables. Tableception, if you will. (Is that joke still a thing? I use it a lot.)

And then on top of that, there are some special little tweaks you can make to the CSS itself to ensure that when the size of the screen shrinks, those tables all shift around into place, so instead of squished, you get stacked.

Screen Shot 2019-10-29 at 1.17.34 PM <– Like that.

So what does this have to do with Pardot??

In a few implementations clients have used one of the prebuilt responsive templates in Pardot and found that instead of stacking, their template just shrank down into a smaller version of the same layout.

For whatever reason this didn’t seem to happen in previews or even with all template layouts, but for this client it did, and I wanted to fix it. It took some digging. And by digging, I mean rewriting the code almost line-by-line to find the issue, but when I did find it, it seemed a little silly.

The key to that fancy table action above working is in the CSS that exists for that email, so before we even start adding our tables and rows and cells and tables inside of cells…we have our CSS classes defined. Think of those classes as references; later in the HTML tables, I can reference my CSS via the class name, and that is used to display the info according to that reference.

But what I found was a table referencing a class that wasn’t there. Simple mistake and simple solution – we just had to drop the appropriate class name (reference) in the CSS, and BOOM! We had a nice, stacked template.

So what happened??

¯\_(ツ)_/¯

It’s possible that the client made some small change during editing that removed that class. It’s possible that on that particular layout, the class just wasn’t included. I don’t know, but what I took away from that was to just check.

This is true no matter the platform. Any time you are using work or designs created by another source for mass consumption and reuse, just take a minute and review it. Become familiar with it. In a way, the HTML/CSS of your email templates is like a manual for a new gadget you’re putting together. It’s tedious to go through it, and wouldn’t we rather just slap the thing together and be done? Sure. But if you take that time at the beginning to introduce yourself, you’re more likely to find little hiccups. You know, before you start putting any real weight on the thing.

 

What I learned this week: Providers & Self-Signed Certificates

I would say that about once a month I have a client or coworker sending me an email that looks like this and asking “what do I do?”

SelfSignedCert has expired
SFDC Expired Certification Notification

I remember getting my first one of these and panicking, and the documentation available for admins with little knowledge of single sign-on is poor. I am pretty sure that we have all found the answer via the Answers section of Salesforce’ Help, as opposed to actual documentation.

I have kept a link on hand to share for just this occasion (it’s here, in case you need it).

Fast forward a few years, and I’m studying security and identify more in-depth than I have in the past, and much like data skew, that involves learning the correct terms for what used to sound like jargon.

As the link above to Salesforce’s help article states, this Self-Signed certificate is most commonly used for Single Sign-On settings, but…what does that mean? As with anything else, stating the purpose or cause of something doesn’t always answer a person’s question. Many people much smarter than me have rightly pointed out that if you cannot explain a concept to a child, you do not truly understand that concept. And Salesforce’s Help Articles aren’t always great for that level of explanation.

So let’s start with the basics: Single Sign-On.

If you work for a company in an office, you may already experience this everyday. You log into your computer, and doing so logs you into other company services – an extranet, your inbox, etc. To varying degree, the idea is in the name – you sign in once to multiple platforms.

Ultimately this works because there are two entities working together to allow this to happen.

The Service Provider is the system you’re being logged into secondarily – let’s say JIRA. This is the platform that is requesting your login credentials. Normally this request looks like a login screen, but for single sign-on the whole point is that you bypass that screen. So instead of asking YOU, it asks the system you’re logging in through.

This initial system is the Identity Provider. It is helpfully passing along your credentials to the system that needs the information.

Salesforce, as you can imagine, can be both. And the self-signed certificate is sort of like your global permission slip. And like a permission slip it needs to be updated every once in a while.

“But I don’t have single sign-on enabled!” you cry.

Well sure, that makes sense. That means that Salesforce may not be a Service Provider in your org.

Have you installed any connected apps, though? Many connected apps walk you through a setup process that includes a handy UI that takes on the heavy lifting of setting up your API connection. During this process, some of those apps may create a certificate, which you’ll see by reviewing your connected apps link to that certificate. Sometimes these will take care of themselves – the third party companies you’re working with KNOW about this, and they plan accordingly, but at the least, you’ll know.

And if you’ve enabled Salesforce as an Identity Provider, even if you’re not using it that way…well, there you go.

Long story short: if you don’t remember setting this up, it’s very unlikely to cause issues, but it’s also very easy to update. Bookmark that link, and next year when you get that email, you’ll be ready.

 

What I learned this week: Data Skew

Disclaimer: In the spirit of full transparency, I learned about data skew a little while ago. But the whole point is “what I learned this week.” In some cases, “this week,” just refers to this week in time…like…last week, last month, whatever.

My first brush with NPSP was as a consultant. I remember very clearly thinking that some of the features would have been very handy for my B2B sales staff back in the day. In a lot of ways it was love at first sight. I still get prickly when people say mean things about it…

[Insert about a half hour of me looking for the best option for a “Don’t talk to me or my son ever again” meme before realizing there could potentially be a better use for my time.]

That said, the first time I started getting error emails at about 2am was ALSO around this time.

You know, this one:

Message: “First error: Update failed. First exception on row 0 with id 001……………; first error: UNABLE_TO_LOCK_ROW, unable to obtain exclusive access to this record or 1 records: 001…………….: []”

And I was flummoxed. What does that even mean? Why are you locking anything? Who said that you needed exclusive rights? And what does this have to do with merging records?

For a while I sort of…ignored it. Honestly it would run again at some point, right? It rarely happened more than once for the same record.

Sometimes I would have dozens of them. Usually right after some major data change or something. I suspected they were related, but I had other pressing concerns, and eventually everything would be sorted.

Over time I filled in the blanks. Unable to lock row meant that whatever the code was trying to do, it couldn’t get update access to the record.

If I spent more than 30 seconds on it, it made sense. A record cannot be edited by more than one person at a time, so why would it make an exception (ha ha – get it?) for custom code.

And then again, for a while, I left it at that.

Enter Data Architect Trailmix, stage right.

A super important part of the large data volume considerations that are discussed in the data architect arena is the concept of data skew. And as I read about it, I was taken back to a project early on, a move from the Starter Pack and a bucket model to NPSP with Household Accounts.

This client was looking to upgrade to the new success pack. They had been using the bucket model for YEARS – more than 50,000 contacts all inelegantly shoved into this single Account called “Individual.”

It was difficult to report on things. It took forever for the record to load.

I knew that there was a correlation, but I could not, especially at that time, explain what it was. I had a sense that having to many child records was a bad thing. I didn’t know what to call it. And I wouldn’t know, until years later, that that very situation was what caused errors during the overnight batch processing.

Data skew occurs when we have too many child records, plain and simple. It has an impact on loading time (you try showing a record and querying tens of thousands of records at one time), reporting, and…yes, automation.

It doesn’t exactly help me fix the errors all the time. Sometimes it’s just bad timing, and not even because of data skew. But putting a name to something makes it more accessible, less concerning.

Carry on, NPSP. Carry on.

What I learned: TDX19

We’re just going to leave the elephant in the room right where it is, so…make peace with that.

I had the great pleasure to attend TrailheaDX last week, Salesforce’s smaller developer conference, in San Francisco. It was my first TDX, but I certainly hope it won’t be my last.

For those who have never been, it is WAY smaller than Dreamforce. Dreamforce spans over blocks and blocks, from Moscone to local hotels, and it’s not unheard of to walk close to a mile just to get from one session to another. TrailheaDX is not like that. It takes place entirely in Moscone West – granted, all three floors, but comparatively, it’s easy.

It also is repetitive. That has some negative connotations, I realize, but hear me out.

Dreamforce takes place over what I’m confident is half of the city, and very few sessions are alike. If you miss a session because you’re on one end of the event, and the session is on the other, then that’s it. You can hopefully catch a recording later.

TDX had some – not all – but some sessions repeated in the theaters, so if you missed it one time, you might be able to catch it again. Not all of the sessions worked that way, but enough of them that I was able to safely select one session over another because I knew I’d get a second chance later during the event.

There was still all of the energy and good vibes of the community; I still got to see a lot of my friends and coworkers.

And this was the first time in years that I simply attended the event. I didn’t volunteer or serve on a panel or do anything but go to sessions and try to absorb, and I’m glad I did. I learned quite a bit while I was there, and I came away energized enough to sit down and write this. Which is no small feat.

I had a bit of an epiphany, as well, that I’d like to share now.

As a self-proclaimed polymath, I have struggled with how best to run this blog. I wrote about it already, but I still never answered my own question.

So I’m going to unshackle myself a bit. Moving forward, I’ll be sharing things I learn – random, and untethered to a single category. Because that’s what’s interesting to me. Sometimes it’ll be Salesforce related, or technology related, or project management related, or…whatever I learned.

That’s what I’m taking away from TDX19, and I’m already looking forward to next year.

Live from Dreamforce

It’s Wednesday – halfway through Dreamforce, and I’m returning from a day and evening of volunteering, playing Dungeons and Dragons, and having dinner with some of my absolute favorite people.

I look back on my first Dreamforce, and I look at where I am today, and I still can’t believe it. How is this my life? How did I get so lucky?

Not to say that it comes for free. I work hard, and I work a lot, but I enjoy my work, and part of my career is experiencing this event (and others like it) every year.

One of the first things I was asked to do this year was fill out a gratitude card – what am I grateful for?

This. All of it. I’m just grateful.

Online Proctoring: My Horror Story

I enjoy my creature comforts. I like working from my couch some days, with blankets all bundled around me, feet propped up, and a cup of coffee nearby. Most importantly I like all of those things in my own house. If offered an opportunity to get coffee at a fancy coffeeshop or make myself a cup of Chock Full O’ Nuts at home, I’m going to pick home. Every time.

So when I learned that certification could be done from home, those many years ago, I signed up immediately. The first online proctored exam I took was not actually for Salesforce. It was my Marketo Certified Expert exam, and I took it in December after signing up for a training course that came with a voucher. I figured it couldn’t hurt. And given that December is prime time for crap weather, I was excited, despite the “it’s not awesome” warnings available online. How bad could it be?

Well…

First my webcam just stopped working. It had been fine, doing its thing, and literally just before it was time for me to sit down and show my stuff, it stopped.

Kryterion was super chill. Their support team rescheduled my exam for an hour later, and I ran out to get a new webcam. Done.

Fun fact: new webcams are better than old webcams. The resolution on my new one was too good, in that it couldn’t match my face because the old picture I had on file for facial recognition didn’t have as high a resolution.

No worries. Super awesome support team reset that. Face recognized. Typing recognized. It was time to take the test. Aced it.

When it came time to take my first Salesforce exam, I figured I had worked out the kinks and could handle anything.

Well…

I just couldn’t log in! After about three or four attempts, calling support, and still not being able to access my exam, we discovered there was a server error on their side. They told me they would reschedule my exam (for free, again, thank you super awesome support team!) and call me when I would be able to log in.

I made myself a drink and watched an episode of the Office. I was halfway through my vodka-cran when they called and said I could get started. Aced it.

I took a few onsite exams after that. Switching it up, I guess. But the testing location was not a huge step up from the headaches I’d had at home, so it was back to online for me.

Testing with a Mac is different. Testing with the new MacBook Pro (with its nearly universally despised Thunderbolt 3 ONLY connections) is actually impossible. Literally. If your external webcam (which you have to use) is connected via a dongle (which is has to be), the feed won’t go through.

For my Pardot exam, it took us about 2 hours to troubleshoot. If not for the super awesome support team at Kryterion, I would still be in the fetal position upstairs. I ended up needing to use the gaming computer to take my exam. Sweet graphics, anyway. I still had to stop like five times to adjust where the camera was or the microphone volume, or whatever.

I’m really not trying to scare you off. Legitimately not my purpose here. But I want you to KNOW what you’re getting into, if you go the online route.

First of all, your test may go way smoother. I had at least two that went off without a hitch. But just in case, keep these things in mind:

  1. If you have a brand new MacBook Pro, just plan on taking the exam onsite or with a cheap-o PC you pick up at Best Buy for like $200.
  2. When they say that you should buy their specific webcam…consider it. I didn’t. I had to buy one last minute, and I just wasn’t going to reschedule. But they have one that works, so you might as well.
  3. Download Sentinel and do your “biometric scan” in advance but not TOO in advance. Like two or three days beforehand is fine. But if you sign up for the exam in June to take in November, just wait.
  4. Be prepared to spend some time getting INTO the exam.
  5. Be prepared to be interrupted DURING the exam to fix something.
  6. Lean heavily on the support staff there. They really are awesome, really patient, and they have the answers.
  7. Be NICE to the support staff. Their job sucks. They just watch a bunch of under-dressed, maybe showered, work-from-home people take exams and get mad all day. And they can help.
  8. Maybe make a drink beforehand?
  9. Definitely eat beforehand – it might be HOURS before you get another chance.
  10. Be prepared to retake the exam. After fighting with computers and getting interrupted and feeling like NOTHING YOU DO IS WORKING, you might not be in the best place to take an exam…so be patient with yourself, too.

Maybe I’m a glutton for punishment, but I’ll probably continue doing the online proctored exams. That is how much I hate driving in snow.