10 Pain Points with Webforms + Salesforce

Share this article...

Forms are essential for capturing data from prospects and customers, and into your Salesforce org. These could be web forms on your website, landing pages, portals such as Salesforce Community (Experience Cloud), or embedded on third-party applications.

Regardless of where you choose to locate your forms, you are prone to errors. These are the pain points that make creating, updating, and troubleshooting forms stressful for Salesforce Admins, marketers, and others around the organization burdened with the responsibility. As Salesforce orgs become increasingly customized and further from their ‘out of the box’ form, ensuring data gets from point A to point B is a mounting challenge.

“Prodly”

In this guide, I will walk you through some painful experiences I’ve had with forms during my time as a Salesforce and Marketing Automation Consultant, spending many hours battling with forms behaving badly. First we’ll look at frictions in the form building experience, data management, and finally the operational struggles.

Note: I will be illustrating my points with images from FormAssembly, a top-rated web form platform for Salesforce.

1. Disjointed form building experience

Your user experience is key to your team’s productivity. There’s a balance to strike; you need the rich functionality at your fingertips (on screen) without an overloaded interface. Performing an action shouldn’t require multiple clicks; instead, navigation bars, collapsable menus, in-app guidance can make a positive impact on how fast you can create your form.

Leading applications in the space have invested in optimizing their user experience. If you’re facing friction with your form builder then you deserve better.

In the video below, check out how the sidebar navigation opens up into options that display horizontally, that when required, open up a secondary navigation menu to drill down into more options:

2. Form styling with code

How a form looks can make or break your brand. Prospects and customers viewing your forms will be unforgiving if the form’s style is not in keeping with your website, landing page, or portal – not only is it jarring on the eye, it is enough reason to mistrust the form and instinctively avoid submitting their data.

Form styling is controlled with coding languages CSS and HTML, which are both skills that need to be learned and practiced over time. Honestly, why do you need to get in the weeds with CSS/HTML, when many modern form builders come with these styling options, all point and click? Instead of hard coding the color of the submit button, you can click it from a color wheel instead. I’m not only talking to the non-technical here, no one should need to waste time unnecessarily.

What’s more, you shouldn’t be manually recreating the same styling on each new form. Packaging up branding as a ‘theme’ (or similar) means it’s reusable to all team members, keeping anything externally-facing on-point.

While research advises against adding multiple columns to forms, you may find yourself in a situation where you need to. Enter more code! Unless you know Bootstrap (a CSS framework), it’s highly likely the code you write won’t be responsive; in short, it’s tricky to get your forms to resize appropriately for users on mobile devices or tablets. Another reason to invest in a form builder that alleviates this hassle entirely.

3. Embedding forms with iframe

When it comes to publishing your webform, you have multiple options for getting it in front of your prospects.

You may know that when embedded on your website, your form’s style may be corrupted when inheriting your website’s CSS (which may not accommodate your desired form look and feel).

One method to publish your form is iframe, which essentially drops your form onto your web page, contained in it’s own frame.

Above: how iframes are embedded into a website hosted on WordPress.

Simply put, the code that dictates how your web page is styled won’t interfere with, or override your form’s style.

4. Data reentry (no unique identifiers)

Moving on to the data management pain points. One of the most frustrating situations when dealing with a company as a consumer or client, is having to re-enter data you know they must store about you, or worse, even information you entered into a form previously.

This is typical where the web form does not have accessibility to CRM data. While every form can send data to Salesforce, some cannot benefit from ‘reading’ your Salesforce database; this means that returning visitors are not recognized.

Prefilling form fields based on who is viewing the form relies on a golden link between the viewer and their CRM record, known as a unique identifier. In the majority of marketing automation platforms, email address is considered the unique ID on the assumption that no two people would use the same email address; that assumption, however, is not a sure-fire way to link the viewer with their data (think husband and wife sharing an email, or duplicate records in your CRM).

In every Salesforce org, the CRM ID is an identifier that is guaranteed to be unique for each record (you’ll see this embedded in the URL of every Salesforce record). You can embed this in the link to the form so that the form can recognise who the viewer is. However, you won’t be able to add this link to public web pages because it won’t be unique to each individual (although, there is a workaround using a two-form process*).

The CRM ID is not the most attractive identifier to make visible in a URL, and your organization may have other pieces of identifiable information you can leverage. Luckily, using robust form platforms for Salesforce gives admins the flexibility to define which data point should be the unique identifier.

How is this a bonus? A customer could, for example, input their account number, passcode, or last order number, and the form field will auto-populate.

*the two-form workaround is something I wanted to call out to prove you should get smarter with your forms. In fact, you can prefill a form with a viewer’s personal information even without them needing to have clicked on a link with an embedded parameter. The two-form process works with the viewer entering a piece of identifying information on the first form, and then is redirected to a second form. What happens behind the scenes when the first form is submitted, is a ‘prefill link’ pulls in the email or other piece of information submitted by the viewer, embedded as a parameter, which becomes the redirect link that sends the user to the second form. With the help of a connector (such as FormAssembly’s Salesforce prefill connector), the fields on the second form are auto-populated with the desired information.

5. Restricting your data capture to certain CRM objects

Once you have your record matching and auto-populating sorted, it’s time to expand your horizons further into your Salesforce data model.

Forms built using marketing automation platforms typically work with the individual – the lead or contact, in Salesforce speak – which means that you only have the option to add lead/contact fields to forms. While this covers the most of marketing data collection use cases, you shouldn’t be limited at times where you need to collect data for other records.

An example would be an event registration form where you would like to capture someone’s RSVP, and sync to the Campaign Member Status field in Salesforce.

Above: an example of a form that will find or create the individual customer’s details when the account section is filled in.

Some organizations have used Salesforce automation and code to build funky workarounds, however, this is error prone and generates “Technical Debt”.

Just as Salesforce gives admins the ability to extend the Salesforce data model, your form building platform should give you the option to ‘reach’ – both create and update – related records.

Above: shows the admin view in FormAssembly. There is the option to map fields from a related object (eg. contacts) in addition to the primary object (account, in this case). Source.

6. Dropdown values don’t match picklist fields

This one difficult data challenge that will sneak up on you.

A Salesforce picklist is a field type where the user must select one value from an expandable menu (known in other contexts as ‘drop-down’ fields). The trouble comes when a change is made to the picklist values in Salesforce, but not updated on web forms.

Managing multiple picklists used on many forms is not sustainable – one change could result in a lot of admin work. What’s worse is that when the form tries to create or update a record in Salesforce, it will lead to errors, or bad data (depending on your picklist field settings).

I’ve seen some form providers that can pull the options dynamically from picklists in Salesforce, refreshing forms with the most current values from your source of truth.

Above: how FormAssembly can pull picklist values from Salesforce dynamically without the admin cross-referencing with Salesforce.

7. Slow data sync speed

The time that passes between a lead completing a form and gaining any response, can negatively impact the likelihood they will do business with you – no surprises there.

How negative, exactly? One study by the Harvard Business Review was able to quantify the cost of delays in the initial lead response time.

“Firms that tried to contact potential customers within an hour of receiving a query were nearly seven times as likely to qualify the lead as those that tried to contact the customer even an hour later—and more than 60 times as likely as companies that waited 24 hours or longer.” – Source

You would be mistaken to believe this is only applicable to B2B companies; a third involved in the study were B2C. Customers don’t want to hang around while their data syncs, for example, from an ecommerce platform to Salesforce.

The moral of the story? Data sync time matters. When evaluating form platform vendors, enquire about the sync time they guarantee (as part of the service level agreement). The higher the volume of data you are syncing, the more important it is to check any connector can withhold stress without compromising on speed.

8. No data sync error logs

Data can sometimes not arrive at its intended destination (the target record in your Salesforce org). There are many possible errors that could cause Salesforce to reject the record – deduplication rules, records not meeting validation rules, data formatting, unacceptable picklist values (point #6), and more.

These ‘kickbacks’ can occur even if you are diligent in mitigating them. Think about how much can change with Salesforce configuration, I bet your org rarely stays static.

If errors are inevitable, then what should you expect from your web forms?

The least you should expect to avoid erroneous records disappearing into the abyss is a sync error log that flag records that didn’t make it across. One that adds a reason why is a godsend for guiding your troubleshooting. One that enables you to ‘replay’ the scenario, essentially resubmitting the record, is a huge bonus.

Above: FormAssembly’s detailed error log that also provides actions to remedy errors.

9. Submission limits

You can predict how many form submissions you’re likely to receive in the next month, quarter, year – for some organizations, that number can fluctuate suddenly.

The most basic connected form option for Salesforce you can use are ‘Web-to-lead’ forms. While they are included with your Salesforce license, there is a 24 hour limit of 500 leads (once exceeded, you will need to enter the leads manually from your inbox). That sounds like a real pain.

Usage-based pricing may work for some teams, however, others could run up a big bill unexpectedly – something to consider when evaluating your options.

10. Substandard security

I doubt there are any organizations processing any customer data digitally who don’t have security high on their priority list – especially since GDPR was instated in 2018, followed by CCPA, and other similar legislation.

This has always been the case for some industries – Financial Services, Healthcare, and Government, to name the most prominent that come to mind.

The fear of data breaches has us gripped so it’s worth understanding how secure your forms are, and any risks posed to data being passed from customers to your Salesforce org.

Aside from investigating security accreditations, another measure you could consider to improve form security is two-step verification, whereby two or more pieces of information are requested from the user before the form displays any sensitive data (point #4).

Above: a basic example of two-step verification that is requesting a combination of email address and phone number to check the viewer is who they claim to be (source).

Summary

This guide has covered key frictions in the form building experience, data management, and operational struggles that I have come across in real-life.

One point you, hopefully, will take away from this guide is that regardless of where you choose to locate your forms, you are prone to errors – that is, until you evaluate how well your form building platform is working for you, or do you end up ‘working for the tool’ running around troubleshooting form errors, picking at HTML/CSS code, or cleaning up data that doesn’t end up where it should be in your Salesforce org.

If these pain points resonated with you, then join us for “8 tips to solve your web form worries”, a webinar we’re teaming up with FormAssembly on, taking place Tuesday, June 29 at 12 p.m. EDT — register now!

Add Comment