Using ZoomInfo to Populate Form Data

The DiscoverOrg and ZoomInfo combined platform has an optional add-on called FormComplete that allows customers to access ZoomInfo contact and related company data from forms on their own website. This helps their end users provide more detailed information prior to form submission. When an end user provides an email address ZoomInfo supplies data for the other form fields (if a match is found).

How FormComplete Works

A ZoomInfo customer has some type of person lookup or other contact-centric processing available on their website. This process works better when several pieces of information about the person are supplied as inputs but not all end users know this information. Instead of trying to process incomplete form data, the customer can now create a FormComplete script to populate most of the data for users. FormComplete can also be used to populate hidden fields not shown to the user when you want reliable information from a credible source.

To do this, the customer decides which fields are needed in the form, maps them to ZoomInfo person and company data fields, and defines a corresponding form in the combined platform web application (with FormComplete enabled) that maps each form field to a specific ZoomInfo contact or company field. Email is required, but customers are free to select any additional fields they wish.

Once the form mapping process is complete, the web application generates an HTML snippet script the customer must use on their website to handle actions from the form.

This script monitors keystrokes in the required email field and sends a query with the supplied email to ZoomInfo once a sufficient portion of the email has been entered. If a match is found, the other fields in the form are populated with data, allowing the end user to submit a much more complete form that conforms to the customer’s expectations.

The FormComplete script also monitors the submit button and saves information about the populated fields for each submission in the customer’s account into the form’s table. This data is available within the combined platform web application in the account that created the form so folks using FormComplete know exactly which people are being requested and what data was populated for them.

As far as the end user’s concerned, the data was magically populated – they have no idea that ZoomInfo was accessed under the covers – and they are just doing whatever the form does on the customer’s website.

Delving Deeper into FormComplete

Each time a customer creates a new form a unique form ID is provisioned. Once the form mapping process is completed, the defined fields and a set of related metadata are turned into an SQL table named with the ID representing the form. For example a form with an ID of 2a0c1db0-f039-11e9-aaef-0800200c9a66 containing first name, last name, email address, and company name might result in a table represented by the following:

When an end user of the customer starts typing in the email field on the customer’s website, the script starts capturing the keystrokes. When the address is entered so that it is representing a valid email address (by reaching the format [email protected]) the handler waits another 150 milliseconds then sends as much of the email address as entered to the FormComplete backend along with the form ID.

ZoomInfo does a person match on the email address (or email address with partial domain information) to obtain the relevant record. If there’s more than one potential match, the highest ranked match (by the default relevancy scoring) is used. If no match is found, no data is returned. If a match doesn’t have all requested fields populated in the ZoomInfo records or if a corresponding company record is not found for a contact, as much data as possible is returned and the unavailable fields are omitted.

ZoomInfo uses the form ID to look up the table representing the form and determine which additional fields are needed in the response to the customer’s website. This data is extracted from the matching person record and sent back to the customer’s website to populate its form (if company data is requested, the company ID stored in the person record is used to gather that information as well). No data is saved to the form table yet, just sent to the website to populate the current iteration of the form.

The FormComplete script also looks for submit button events and, in conjunction with whatever form processing the customer does for the end user, sends a message back to ZoomInfo to store the form data and any relevant metadata in the table matching the form ID. Each row in this table represents a single successfully submitted form. Note that the customer processing of the form is independent and ZoomInfo keys solely off of button click and not form processing; if the form data cannot be processed by the customer for any reason it is still stored in the FormComplete table as if it was successfully fulfilled. However, if the end user abandons the form for some reason, the data is not stored in the ZoomInfo table for later access. ZoomInfo plans to add support for storing abandoned form information in future versions of FormComplete.

If they choose to do so, the customer can view all submitted data for each of their forms (pulled from the relevant table) within the combined platform web application.

Final Thoughts about FormComplete

Incomplete form data can make it difficult to process end user requests. The new FormComplete add-on to the DiscoverOrg and ZoomInfo combined platform helps solve this problem for websites with forms requiring information about people. Once a user enters an email address, ZoomInfo can fill in the rest of the required data for them. This allows for better input data for form processing and a better experience all around. It also provides more leads and information about leads for our customers and their marketing and sales teams.