I have a superpower that most people don’t have. In my position here at Service Objects, I have had the privilege of being a fly on the wall with many companies while helping them create clean and validated data. So I know, perhaps better than most people, what businesses go through as they wrestle with how to improve their data quality and ROI.

In this article, I would like to take you inside the mind of a typical business as they look at their data challenges, and what happens when they decide to work with us. You probably know what *we* think about our products, of course – but the only opinions that really matter are those of our customers. So let’s look at a hypothetical case study of a typical business, based on my many actual interactions with prospects and clients.

Discovering your data quality issues

I was a new hire at my company when it all started. We were a large manufacturing firm serving the business-to-business market, and things were ramping up. We had a website where people could make orders and sign up for a catalog, as well as opt-in for email alerts when special items would go on sale or we had an email campaign.

My job was ensuring that the data we were collecting was accurate and up-to-date. And I found that this data was a mess! For one thing, we had lots of inconsistencies in our contact data. Sometimes street suffixes and street prefixes were abbreviated, and sometimes they weren’t. Sometimes they were in all upper case, or all lower case, or sometimes mixed case. The same things were also true for the state field. One of the complaints from management was that the shipping labels on our catalogs looked very bad.

More importantly – particularly from a financial standpoint – the team was getting frustrated with the amount of “return to sender” items we were receiving. This gave us a few problems to solve. First, I knew that our data input forms would need to be updated, but I also quickly realized that somehow forcing our users to always provide good consistent data was a pipe dream. Standardizing the data alone wouldn’t fix the problem of returned catalogs, so I knew that this really came down to getting our existing data standardized and validated, as well as making sure new addresses coming into the system were also high quality and valid. Address validation was the key to solving this.

Finding an address validation solution

Now a decision needed to be made: do we get our software engineers involved and build it ourselves, or do we get something off the shelf? I had faced this dilemma before in previous positions. For small tasks, building solutions from scratch is OK and can save money in the long run. But I have found that when trying to implement solutions for larger projects, finding products off the shelf can have a much greater impact.

You see, the problem really wasn’t that we couldn’t update our forms to help standardize the inputs. It was a small job to switch data entry fields from open text fields to dropdown selectable options. The tough part was the address validation component. We were experts with our products, but it really didn’t make sense to try to be experts with address validation. Address validation is no simple task, and I knew the right solution would be finding a company that had a lot of experience with it.

Naturally, like everyone else, I did a Google search for “Address Validation”. I was looking for three main things for our solution. First, they had to be experts. Second, they had to have integration options, because I knew I wanted a solution that integrated with the forms we had on the website. I also didn’t want to have to build out a process to clean the existing addresses: I wanted to simply send the data over in a file have it cleansed and returned to me to repopulate our database. And third, I wanted service. I wanted a company that was available to talk when I needed to talk, and would respond quickly to my email questions.

It turned out that Service Objects had all of this and more. I had access to experts with solutions to my problems – not just people selling solutions, but also the people building and integrating these solutions. And it turned out that our team didn’t really need much help integrating the Service Objects’ Address Validation solution into our website. The documentation and sample code were clear, and with just a free trial key we were able to get up and running. Then all we needed to do was switch to a live production key, and we were done! I really like it when things are that easy.

When it came to validating the existing addresses, we wanted a solution where we could upload our data and get it cleansed and returned to us, like I mentioned earlier. After talking it through with a Service Objects representative I realized that we just didn’t have one data set to cleanse. In addition to our direct data set needing to be validated, we would also be importing address data from other divisions of the company on a periodic basis.

Here it would be nice to set up a process where we could regularly deliver a file and have it processed. After talking it over some more, Service Objects told us that they did do one-time processing, But also offered an automated batch service where we could upload a file that would get processed and returned to us automatically. This was exactly what we needed.

Moving on to email validation

So we integrated address validation into our system and got the automated batch process going, and everything was running like a well-oiled machine. Address data was coming into the system as clean as it could be, and the issue with returned catalogs disappeared. Next, I wanted to tackle the issue we were having with our email alerts that visitors could sign up for.

It was being reported that we were getting a lot of bounces on the email offers we were sending. When I examined the email data, some of the reasons were obvious. I was finding things like emails that appeared to have been entered by the user mashing a bunch of random keys on their keyboard. But the problem was larger than that – we were also getting bounces from emails that appeared legitimate.

I recalled from my conversations with Service Objects that they were experts in several types of data validation. Besides address validation, for which they had Canada and international products as well, they also had phone validation services, geocoding services, lead and ecommerce services, demographics services and more. But most importantly, for my purposes, Service Objects had a solution for real-time email validation.

The solution I was looking for would be one where we could validate an email at the point of entry into our system, and also one where we could send automated batches to get validated before we do an email campaign. The automated batches would also help us with the multiple email lists that we purchased or rented. The Service Objects’ Email Validation service was perfect for this, and was just as easy to integrate as the address validation service was.

Lessons learned

This case study tried to identify a few phases companies go through when they try to validate their data. They involve identifying what the problems are, and sometimes these problems are not always obvious. Moreover, validating your data once does not mean that you are done. For starters, email addresses change and people move. Also, if your records are of people in the European Union then personal data needs to be as accurate and current as possible, particularly in light of their new GDPR regulations.

Stale or incorrect data is your enemy, and we have the services you need to keep it valid. After identifying the problem, most companies look next at how and who should solve the problem. As I mentioned in the case study, there are reasons to build out solutions in-house, but when you get into the realm of data validation it is really best left to the experts.

There are additional benefits to buying off the shelf with us besides our capabilities and expert support. You also benefit by always having the latest and greatest versions of our products. When we update our services, these updates are often injected into the operations you are already using and can provide for faster response times as well. Also, nearly every customer goes through a discovery phase where they are learning about a service and all the different data points that it can return. There are a lot of terms involved, and unless you are an expert some of them can be confusing. In cases like these, our assistance can make a big difference.

We’re here to help

Above all, we are there with our customers every step of the way. And there are often times when some expert advice can help you get more out of our services.
For example:

• For email validation, you may want to know what greylisting is or what catchall means, and how knowing these data points can help you.
• For address validation, it may be very helpful to know when an address is classified as residential, so you can better define shipping costs.
• You may not be aware how some of our capabilities could directly profit your specific operations, such as demographic analysis or lead validation.

We are always here to help you understand our capabilities, as well as helping you through the integration process. Integration is usually the last main phase in the process. We do find that most organizations have few real issues when it comes to integration, but there are unique cases that we work through together. We have lots of documentation and sample code to help with integration, and you can count on us as a resource for help.

This hypothetical case study has a lot in common with our real-life experience with customers: they come to us with data quality issues that are costing them money, hurting their productivity or damaging their brand image. And then we collaboratively help them find solutions to these problems, and make it look easy. We would love to help you too!

Contact us any time for a no-obligation discussion on what we can do for you.

Data gets stale over time. You rely on us to keep this data fresh, and we in turn rely on a host of others – including you! The information we serve you is the product of partnerships at many levels, and any data we mine or get from third party providers needs to be up-to-date.

This means that we rely on other organizations to keep their data current, but when you use our products, it is still our name on the door. Here at Service Objects, we use a three-step process to do our part in providing you with fresh data:

Who: We don’t make partnerships with just anyone.  Before we take on a new vendor, we fully vet them to be sure this partnership will meet our standards, now and in the future. To paraphrase the late President Reagan, we take a “trust but verify” approach to every organization we team up with.

What: We run tests to make sure that data is in fact how we expect it to be. This runs the gamut from simple format tests to ensuring that results are accurate and appropriate.

When: Some of the data we work with is updated in real time, while other data is updated daily, weekly, or monthly.  Depending on what type of data it is, we set up the most appropriate update schedule for the data we use.

At the same time, we realize this is a partnership between us and you – so to get the most out of our data, and for you to have the best results, we always suggest that you make sure to re-check some of your data points periodically, regardless of whether you are using our API or our batch processing system. Some of the more obvious reasons for this are that people move, phone numbers change, emails change, areas get redistricted, and so on. To maintain your data and keep it current, we recommend periodically revalidating it against our services.

Often business will implement our services to check data at the point of entry into their system, and also to perform a one-time cleanse to create a sort of baseline. This is all a good thing, especially when you make sure that data is going into your systems properly and is as clean as possible. However, it is important to remember that in 6-12 months some of this data will no longer be current.  Going the extra step to create a periodic review of your data is a best practice and is strongly recommended.

We also suggest keeping some sort of time stamp associated with when a record was validated, so that when you have events such as a new email campaign and some records have not been validated for a long time – for example, 12 months or more – you can re-run those records through our service.  This way you will ensure that you are getting the most out of your campaign, and at the same time protect your reputation by reducing bounces.

Finally, here is a pro tip to reduce your shipping costs: in our Address Validation service, we return an IsResidential indicator that identifies an address as being residential or not.  If this indicator changes, having the most recent results will help your business make the most cost-effective shipping decisions.

For both us and you, keeping your data fresh helps you get the most out of these powerful automation tools. In the end there is no specific time span we can recommend for verification that will suit every business across the board, and there will be cases where it isn’t always necessary to keep revalidating your data: the intervals you decide to use for your application will depend mostly on your application. But this is still an important factor to keep in mind as you design and evaluate your data quality process.

To learn more about how our data quality solutions can help your business, visit the Solutions section of our website.

“Can’t you just add that feature today!?”

“Can you add a simple update for this!?”

“It’s obvious, it really shouldn’t take very long to implement!”

Software developers hear statements like this more than about half a million times over their career.  It raises my eyebrows every time I hear it, typically giving me a little chuckle inside. In all honesty, it is not a surprise that those kinds of inquiries come up and that they come up as often as they do. After all, these queries come from people that do not code so, from their perspective, the questions seem legitimate.

Errors, Intent and Responsive Address Validation

Fundamentally, these are legitimate questions. The misconceptions that trigger this type of confusion often stem from how well humans can quickly find patterns, errors and solutions. So rapidly, in fact, many problems appear to have “fast” or “obvious” solutions.

For example, to us, it may seem obvious that in our Service Objects address the typo “Cta Street” should be “Cota Street” or “Santa Barbra” should be “Santa Barbara.”  These errors are relatively easy to identify, fix and classify right? For humans, the answer is yes. For a computer, on the other hand, the answer is, well…maybe.

At its heart, the issue involves underlying questions about conceptual intent and programming capabilities. For example, when the name of a city is corrected, what does that mean for the data related to the corresponding physical address? Does St. Louis being changed to Saint Louis maintain the fidelity of the locational intent? What about changing Santa Barbara to nearby Goleta? Would these solutions fall within what would be expected behavior?

While both actions result in changes to a piece of information, each solution is based on a different procedure. The first follows a standardized correction of the name of a specific location, which is a type of change to the input. The second, on the other hand, signifies a change in the place itself.

Variations on a Standard: Address Line 2

When it comes to address validation, there are more than enough address variations to examine that constitute a standard address format, and that’s just talking about Address Line 1.  Though Address Line 2 is not a standard address field, it has been a custom to see that field in one of it’s many variations on forms when we fill out our address.

Address Line 2 has often left users confused as to what information should be included in that field. While many argue Address Line 2 is designed for apartment numbers, suites, and similar secondary information, there is no consensus. In fact, the USPS does not recognize Address Line 2 as a standard address field.

Reactive Address Verification

In practice, the field is often used for apartment and suite numbers, but also for other details like ‘care of’ or to give additional information to the mail delivery person.  Almost anything can go into Address Line 2, and increasingly, people expect Address Line 2 data to be handled as part of the entire address validation protocol.

Ultimately, this field adds a significant layer of complexity to an address validation solution. Take for instance the scenario where someone enters “Apt 2 A C O Sally” on Address Line 2. Typically, someone would not enter the data that way, but you may be surprised how often something like this does come up. Visually, we can easily identify the intention of the data. An address validation process, on the other hand, will find identification and categorization of this information difficult. For example, what does “Apt 2 A C O Sally” signify? Is it Apt 2A, Care of Sally? Or is just Apt 2? Furthermore, once we identify the “Care Of” details, does that information need to be preserved on the output?

Standardized Solutions and a Custom Fix

In some situations, Service Objects can create a solution capable of handling the complexities of multiple address data inputs beyond the standard format. In other instances, the best result is a happy medium. Sometimes a specific solution can be tailored to a particular client based on their individual needs. Always, our updates can fine-tune operations and benefit all of our clients.

We use our extensive validation knowledge and industry standards and expectations to help govern which approach we take. Situations like these represent what our teams look at all the time, and we are always finding ways to make improvements. Our services are based on almost 20 years of experience.

When we update logic in the system, we often walk a fine line between what the code should do versus what it already does.  We always want to improve our processes without negatively impacting clients already used to expected behavior. Improvements capable of changing the expected results for current users will often be bundled up in a new version, but usually, we can find ways to update current versions, so clients always have the latest and greatest option without needing to make any changes.

As we know, the devil is in the details. By drilling down to the smallest and most incremental element of an address input, Service Objects provides the highest level of data verification and address validation services. In fact, our focus on details allows us to be experts in the validation services field, so your organization doesn’t have to be.

 

We are back now with the fourth blog in our Salesforce Data Quality Tools Integration Series.  In previous blogs,  we covered various topics like; creating a plug-in that could be dropped on a flow, a trigger and Apex classes.  From these blogs, you can learn how  Service Objects APIs will help improve your data quality and in turn,  the performance of your Salesforce instance. Like the VisualForce app demonstration, this demo shows how you’ll be able to extend our services for your own purposes in Salesforce’s Lightning framework.  By the end of this blog, you’ll have all the code you’ll need to get started, so don’t worry about implementing this step by step.

This Lightning app is going to serve as a quick email contact input and validation tool.  We will use separate custom objects and custom fields to make this app stand alone from your other objects in Salesforce.  With that said, please note that everything I demonstrate is totally customizable.  For the purposes here, that means you can adjust which objects and fields (standard or custom) you want to use.  You will also be able to customize the call to our Email Validation API and insert your own business specific logic.  There are a lot of code files in this project but do not be discouraged.  This only means that the code is broken down into byte size parts and abstracted to keep the logic a UI separate.

First things first, we are going to start with some basic setup.  Unlike VisualForce, before we can work with the Lightning framework, we will need to turn on My Domain in Salesforce.  You need to have your own sub domain for your Salesforce org, and that is what My Domain does, it allows you to create a custom sub domain.  You can find the settings under Company Settings when using the Lightning Experience.  This link will take you through the details on setting it up.  After you have activated it, you may need to wait several minutes before it is ready. Salesforce will email you when it is done.

The next part of the setup is setting up the Service Objects endpoint.  I am not going to go over it this time because I go over it in the first and second parts of this series.  So, if you need help with setting this up or want a description of what this is, then I would refer you to those blogs.  If you have been following along from the first two blogs, then you would’ve had completed this part already.

In the VisualForce demo, we jumped right into creating the custom fields, however, this time we need first to create the custom object that will house our custom fields.  In the Object Manager, click on Create and select Custom Object.  From there, you will be prompted to fill in several details of our new custom object.  Here is what you will need to add:

• Label
  • Email Contact
• Plural Label
  • Email Contacts
• Starts with vowel sound
  • Check
• Record Name
  • Name
• Launch New Custom Tab Wizard after saving this custom object
  • Check

That last check for launching the New Custom Tab Wizard will create a custom tab for you to be able to add/edit/delete during testing before we create the final home for our app.

Next, you will need to add the following custom fields to the newly created Email Contact object.  If you are customizing this for your own purposes, you will want to add these fields to the object you are working with.  If you want to map more of the fields that we return from our service, you’ll have to create the appropriate fields on the object if there isn’t an existing field at your disposal.  If you are using existing objects for these fields, you will want to take into consideration the names of the fields, to prevent conflicts or confusion in your system.

• Field name
  • Internal Salesforce name
  • Type
  • Service Objects field name

• Email
  • Email__c
  • Email (Unique and required)
  • EmailAddress

• Status
  • Status__c
  • Picklist
    • Review (Default)
    • Accepted
    • Rejected
  • None

• Score
  • Score__c
  • Number (1,0)
  • Score

• Notes
  • Notes__c
  • Text (255 and default set to “None”)
  • NotesDescription

• Warnings
  • Warnings__c
  • Text (255 and default set to “None”)
  • WarningDescriptions

• Errors
  • Errors__c
  • Text (255 and default set to “None”)
  • Type, Error.Description

• Is Deliverable
  • Is_Deliverable__c
  • Picklist
    • Unknown (Default)
    • True
    • False
  • IsDeliverable

• Is Catch All Domain
  • Is_Catch_All_Domain__c
  • Picklist
    • Unknown (Default)
    • True
    • False
  • IsCatchAllDomain

• Is SMTP Server Good
  • Is_SMTP_Server_Good__c
  • Picklist
    • Unknown (Default)
    • True
    • False
  • IsSMTPServerGood

• Is SMTP Mailbox Good
  • Is_SMTP_Mailbox_Good__c
  • Picklist
    • Unknown (Default)
    • True
    • False
  • IsSMTPMailBoxGood

Ok, so I didn’t promise some of this wasn’t going to be tedious, but at least it wasn’t hard.  This time around, we are adding more custom fields with default values and picklists.  Do not skip the default values; they are key in some of the ways the code works.

Now that we have that out of the way, let’s take a look at what we are going to build (I fudged some of the values so we could see all states of a validated email on the interface).

Below is a better view of the functionality.

Simply put, we will be building out a UI that with take a name and an email as an input and validate the email against Service Objects’ Email Validation API and display the results to the screen.  The validation portion will automatically evaluate the score of the email from the service and assign the appropriate status flag to the record.  In our scenario, I decided to let all the emails with scores of 0 and 1 automatically be accepted and all those with scores of 3 and 4 automatically be rejected.  The emails that scored 2, I left in the review state for the status field so that the end user can make the final analysis and assign the appropriate status flag.

In order to figure out all the different components we are initially going to need, we will re-examine the layout from above.

Taking a closer look, there are five parts identified from the UI that need to be created.  There are a couple more parts beyond what I have highlighted in the screenshot, but I will get to those as we go.  At this point we have identified the following components are needed:

• Email Contact Container
  • A place to put all the parts
  • Filename
    • cmp
  • Email Contact Header
    • Self explanatory
    • Filename
      • cmp
    • Email Contact Form
      • Somewhere to add information
      • Filename
        • cmp
      • Email Contact List
        • A place to add the results
        • Filename
          • cmp
        • Email Contact Item
          • A single result
          • Filename
            • cmp

From there, the UI could be broken down into even smaller parts, but for this demo, this is as far as we will need to go.  Note, in retrospect, I would have used different filenames that don’t start with “Add” but what is done is done.  Next, I am going to go through each of these and briefly talk about the code.

I am actually going to start with a file I didn’t mention above.  It is the file that the app will run through: AddEmailContact.app.  It is simply three lines of markup that says what resources (slds for styling the page) the page is going to use and an element which is our app container, the AddEmailContactContainer component.

Well, that makes an easy transition to the next page, the AddEmailContactContainer.cmp page.  The first thing you will notice is that we assigned the EmailContactUtil as the controller for this component.  The EmailContactUtil.apxc is the Apex class file that will act as the server side controller where, in contrast, a page called AddEmailContactContainerController.js will serve as the client side controller for the component.  Another important thing to note is the list after “implements.”  I am not going to go into it here, but you will need this if you expect to drag and drop this component in the Lightning App Builder in the future.  Be sure to set access to global as well.

This component takes in a list of EmailContact custom objects in the first attribute element and the list will be used to display the current EmailContact records.  After the attribute element, we have three handler elements named init, updateEmailContactItem and createNewEmailContactItem. Those handlers are used for initializing/updating the page (init) and registering two events that will occur later on in the other components.  This component will listen for creating a new EmailContactItem and updating an EmailContactItem.

The init handler is important to mention now because it is how the app gets the list of EmailContacts to display.  The init handler calls the doInit method in the AddEmailContactContainerController.js page.  Asynchronously, the method creates an action to call the server side controller to pull back the needed records.  It makes sense that we are calling the server side controller since we need to be retrieving stored records.  So this method makes a call to the getEmailContacts method on the server side controller and creates a callback that will update our emailContactItems attribute on the main controller so that we can display the records found.

This process will be called on the page being loaded initially and whenever there is some sort of post back, which is useful since we want to display the latest list when new items are added.  And that’s it for the init functionality.

I mentioned the two controller files earlier, but there is one more file associated to the AddEmailContactContainer component, a helper file called AddEmailContactContainerHelper.js.  I will run through these associated files later.  The remainder of this markup page simply references the other components that this page is composed of: AddEmailContactHeader, AddEmailContactForm, and AddEmailContactList.  The AddEmailContactList component takes the input list from this page as a parameter as we will see coming up.

Next, I will quickly run through the header page.  There really is not much to it.  Besides some out of the box styling and accessing an icon from the Salesforce predefined set of icons, it is not much more than a title.  Which makes sense since this is a simple header component.

The AddEmailContactForm is a simple form component.  The parts of this page are the attribute or parameter that we will save the input data, registering an event and the form input section itself.  The attribute will be the variable that holds the input data and will be of the EmailContact type even though we are only populating the Name and Email portions of the object.

Next, we register the event that this component will be firing off whenever the button is clicked. This is the same event that the AddEmailContactContainer component was set to listen for and to handle.

Events need an event file, something that I would describe more as a signature for the event.  It’s a very basic file, so I am going to pop in and out of it quickly.  It is defined within the event element and has an attribute defined with a type, which is our EmailContact object, and a name.

Now back to the form file.  The form section will have input areas for the Name and Email of the contact followed by a button to submit the entry to the system.  In this case, both inputs are required and will provide errors when they are missing or if the email is not in the proper email format.  This component also has a controller and a helper file, AddEmailContactFormController.js and AddEmailContactFormHelper.js respectively.  Both files are there to do basic form validation, help setup and fire the button click event and clear the form.

AddEmailContactFormController first checks to see if the inputs to the form had basic validity.  You’ll notice that the inputs in the form had the same aura:id, which is allowing us, at this point, to pull all of the inputs back at once in an array.  Upon the inputs being valid, we pull the newEmailContactItem variable that was populated with the inputs and send it off to the helper page.

The helper file instantiates the event and sets the parameter for it, which, in this case, is the newEmailContactItem.  Then the event is fired, and the input attribute that fills the form is reset to make the form ready to take in more contacts from the user.

In order to continue with the flow of what is happening with the event, I am going to jump back to the main component and look at its controller and the helper files.  At this point, the user has entered data in the form, clicked the button and the code has setup and fired the event.  Now, the AddEmailContactContainer takes over because it has been listening for this event and is ready to handle it with the createNewEmailContactItem handler mentioned earlier.  The action on the handler is to pass control to the handleAddEmailContactUpdate method in the client side controller.  AddEmailContactContainerController, which pulls in the EmailContact variable from the event that was fired, sends the EmailContact variable off to the addEmailContact method in the helper file.

Now on to the AddEmailContactContainerHelper.js file.  This app is going to both create email contacts and update them.  Since updating and creating are very similar in our scenario, we will have both update and create functions call the one save function.  Much of the code is the same, so it makes sense to reuse code here. Since we are following the path of the create event, we will look at it from that perspective here.  The two methods we will run through are the addEmailContact method and the saveEmailContact method.  The addEmailContact method immediately calls the saveEmailContact method, but it provides parameters for indicating if we are doing an update or create and it also supplies a callback function.  The callback gets the list of new records and sends them to the AddEmailContactContainer after the new EmailContact record is created.  The new Email Contact record is created in the server side controller and is called from the saveEmailContact method.

And that completes the code flow of creating a new Email Contact record.  Next, I am going to jump into the last portion of the code, and that starts with the AddEmailContactList component, where we will look at the displaying of the Email Contact items and the event to update the Status field when there is a button click.

The AddEmailContactList component is another simple and straight forward page.  It handles displaying the list of Email Contacts sent to it through the emailContactItems attribute.  The code iterates over the emailContactItems attribute dynamically displaying the AddEmailContactItem to the screen.

Moving to the AddEmailContactItem, we see that it is a little longer than the reset of the code but in its parts, it is still pretty straightforward.   So what are the parts?  We see there is a graphic and a title, a couple of fields, some buttons, a status and, finally, some fine details.  We could have broken this out into smaller components, but for this demo, this is enough.

In the code two things happen before the header markup is added.  First, just like the event we registered for the button that adds a new contact, we need to register an event for the buttons specific to each EmailContactItem on the page.  The purpose of these buttons will be to allow the user to accept or reject an email based on the information from the Service Objects Email Validation API operation.  The buttons should not be visible unless the score returned from the service is 2.  Scores of 0 are no-brainers, we can, without hesitation, mark those as accepted.  Those are valid emails.  A score of 1 has a very high certainty to be valid, so we will also automatically set their status as accepted.  Those with a score of 4 are bad emails, again, we automate these, but this time we set the status to be rejected.  And 3’s are near certainty that they are bad emails, so those are also automatically marked as bad.  The grey area is those that get validated with a score of 2.  This score represents unknown for various reasons, and we suggest some kind of manual review or inspection.  For more information about the score field and deeper details about service, you can check out our developer guides here.  After we register the event, we setup the attribute element, creating a local variable input that takes a single EmailContactItem.  This should be familiar by now based on some of the other pages we discussed.

Now we get to the graphic/icon and title code.  Nothing too interesting here really, so I am going to skip over it.  But I do want to mention; this code will display our item icon and the title, you will notice that it actually houses the item parts.  All of the rest of the items components will go in here.  If you want to change the icon, you can see a list of what is available at this link.

The next bit of code does several things.  First, it displays the contact name and the associated email.  Then, based on the score determined by Service Objects’ Email Validation operation, we will, in the markup, decide if we should display the buttons used for accepting or rejecting the email address.

Next, a similar markup and logic is used to determine the background color on the status and score sections.

There are several techniques to do this dynamic display instead of using the if/else markup elements but I just learned about them, and I wanted to give them a shot.  I would have probably used a different solution involving Javascript, and this code would have been much shorter.

The last part of this component is the Lightning accordion section.  I added a two-part accordion, so I had a place to display some details that came back from the Email Validation operation without consuming too much space on the screen.  I have it default to opening the second section of the according first.  The first part contains the warnings, notes and/or errors.

The second part contains other various details like if the email is deliverable or is the email on a catch-all domain, as well as, is the SMTP Mailbox good or is the SMTP Server good.  If you wanted to adjust the code and display more data returned from the Email Validation operation, I would recommend adding those fields to these sections or adding more accordion sections with more fields to display.  This is the code for the second section.

That does it for the markup pages.  Now, let’s just follow through the code for when either one of the buttons is clicked.  The rest of the functionality rests on the controller and helper of the AddEmailContactItem page but also some of the pages we already went through from the first event we discussed.

The accept and reject buttons each have their own method they call when clicked.  I could have used just one method here and checked the name or id of the calling event, but I thought this would keep things clear.  These are really just pass-through methods that indicate if the accept or reject button was clicked by passing the true or false to the updateEmailContactItem method in the helper file.

In the AddEmailContactItemHelper.js file, the method updateEmailContactItem starts by setting the status field for the contact item based on the input parameter.

Once that is set, we create the event, fire it and hide the buttons from the screen.

You may have noticed that we are not creating a new event file.  Since the signature for the create and update events are the same, we are able to reuse the one we already have.  Now, like before, the AddEmailContactContainer is listening for the event, but this time it is listening for the update event.  When the event is fired, the main controller will catch the event and call the handleUpdateEmailContactUpdate method in the AddEmailContactContainerController.  The handleUpdateEmailContactUpdate method pulls out the EmailContactItem that was passed in the event and sends it along to the updateEmailContact method in the helper.

Earlier, when we were running through the create functionality, we came to a point where we wrote one save method because we knew that the save method could server both the save and update purposes.  Now we get to utilize what we setup earlier and piggyback off of the save code.  In the AddEmailContactContainerHelper the method for updating, the updateEmailContact method, will call our saveEmailContact from before but this time we are not sending along a call back method.  The saveEmailContact method then sets up a couple of parameters and calls the saveEmailContact on the server side controller, and that controller saves or updates the record.

Now that we have gone over all the code you can see that none of this is terribly difficult to understand, but there are a lot of files for a simple app.  We could have reduced the file count if we put all the helper code back up into the controller code.  We also could have reduced the number if we created fewer components and grouped everything together.  And though you can do all that, there are reasons I didn’t.  One reason to break the application out this way is so that we can focus on smaller parts and make each page more basic.  Another reason is that as you extend this solution to meet your own requirements you may be adding a lot more code and keeping the code compartmentalized like this will help with code readability and maintenance.  When you look at the files for this project, you will see that there were several CSS files that we didn’t go over here.  You can review those as you see fit.  Another thing that I didn’t do, is add more error checking which you will certainly want to do, as well as, writing your own unit tests.  The last thing you need to make sure of, is to get a license key (live or trial) from us and add it to the EmailContactUtil.apxc file, otherwise you will not be able to validate email addresses against our API.  If you get a trial key, you need only update the key in the code.  However, if you get a live key, then you will want to update the endpoints in the code in addition to the key.  With the live key, you will want the first endpoint to be ws.serviceobjects.com and the second to be wsbackup.serviceobjects.com.  In the example below, I changed the key to contain X’s instead of real values.

So, where do you go from here?  One thing you will likely want to do is customize the solution.  Maybe your want to incorporate some of the standard objects in Salesforce or perhaps you want to use or create your own custom objects.  Maybe there is additional business logic that you want to apply to the results our Email Validation.  After that, you will likely be adding this component to a Lightning app.  Or maybe you’ll just use the code for the Email Validation alone for something completely different.  A side note to make here is that you can even apply this demonstration to many of our other services like Address Validation, Address Detective, Lead Validation, Name Validation and more.  When you look at this solution, you should notice that though the part of the code that dealt with calling our Email Validation API was very short, it had a huge impact on the utility of the app.  If you want some specific code that can help with this solution or applying this solution to our other services then simply reach out, and we’ll do our best to accommodate.

“Nobody is perfect. And my company wasn’t even talking about things like data quality ten years ago. So, what is the big deal if there are a few problems with my contact data? That’s life, isn’t it?”

Actually, it is a big deal. First, it affects your costs and competitiveness. Second, it affects your reputation in the marketplace. And finally, because bad data can be so easily fixed with the latest automated tools.

With new regulations on the horizon and an increasingly competitive marketplace, companies need data they can rely on. If you’re still on the fence, below are some of the main reasons your business needs confirmed data.

Saving Time and Money

Bad data always costs your business time, money, or both. It affects areas such as sales leads, delivery accuracy, your reputation when sending email marketing, and much more. It is estimated15-25% of contact data is inaccurate, incomplete, fraudulent, or out-of-date, and a great deal of resources are wasted due to inaccurate or straight-up bad data.

Getting sales leads is costly for most organizations, especially when leads are bad or inaccurate. The earlier you can validate incoming data, the better you will be able to utilize your resources.  Our Email and Address Validation services can help make sure your incoming contact data is coming in clean and valid, and our Lead Validation service helps prioritize your resources toward better targeted leads.

Improving Your Marketing Efficiency

Think of all the wasted resources involved when materials are sent to the wrong address, or salespeople chase after bad or mislocated prospects. Even a small percentage of errors can result in a great deal of frustration for everyone involved, and fixing these problems is low-hanging fruit you can easily automate.

Beyond our Address Validation services, our Address Geocode product can translate addresses to exact latitude-longitude coordinates in real time. For incomplete addresses, our Address Detective product can prevent you from purging good leads. It fixes fatal addressing errors by filling in the gaps of missing address data in your contact records, using a fuzzy-matching API that returns a confidence score for each updated address.

Protecting Your Email Reputation

Suppose you bought an email list and you are ready to send the perfect email, after weeks of refining. Nothing can give you a bad reputation quicker than sending email to a bunch of addresses that bounce, not to mention getting mediocre results from your campaign.

Use our Email Validation service to keep your reputation in good standing. Using a real-time API can reduce bounce rates up to 90%. Our service can process rented lists as well as your own house lists, giving you valuable insight into your contact data assets to make sure you get the most out of your investment.

Cleaning Up Your Existing Contact Data

We often hear people say, “What if I just realized we were doing things wrong and I want to get our data on the right track?” Once your database gets corrupted with uncertain data, typically two things must happen to reverse course. First, you need to draw a line in the sand and commit to making sure to validate any new information going into your system. The next step involves validating all your current database information in a separate process.

We can help automate much of the extra work of cleaning up existing data. We have lots of sample code and support many platforms to make it easy to integrate with us, not to mention the top-notch technical service team we have standing by to help you implement a robust solution.

Lather, Rinse, Repeat

Finally, we wanted to mention the importance of keeping your data current. Even after validating data coming into your system using our API or cleansing your system afterward with our batch process, data will still get old and invalid over time. People move, new homes are built, old buildings are repurposed, emails change, phone numbers are disconnected, and so on.  Like showering, regular data hygiene will help keep your data in the best condition possible, and we make this easy for you.

There are many benefits to keeping your data as up-to-date and accurate as possible, and we are here to help you every step of the way. Contact us to see what we can do for you and your data!

 

In an ideal world, data entry would always be perfect. Sadly, it isn’t – human errors happen to end users and call center employees alike. And while we make a good living cleaning existing bad data here at Service Objects, we would still much rather see your downstream systems be as clean as possible.

To help with that, many organizations are getting an assist with Google, in the form of the Autocomplete with their Places API.  If you setup your form properly and use their API you can have address suggestions appear in a dropdown for your end users to take advantage of to help enter correct data into your system. That’s great, isn’t it?

It does sound great on the surface, but when you dig a little deeper there are two problems:

• First, Google Places API often does not often suggest locations to the apartment or suite level of detail. The point is that a considerable segment of the population lives in apartments or does business on separate floors, suites or buildings.
• Second, the locations the Google Places API suggests are often not mail deliverable. For instance, a business may have a physical location at one address and receive mail at a completely different address.  Or sometimes Google will just make approximations as to where an address should be.

For example, check this address out on Google Maps: 08 Kings Rd, Brighton BN1 1NS, UK.  It looks like a legitimate address, but as the street view shows, it does not seem to correspond to anything.

These issues can leave gaping holes in your data validation process.  So, what can you do? Contact us at Service Objects, because we have the perfect solution: our Address Suggestion form tool. When combined with the Google Places API you will have a powerful tool that will both save time and keep the data in your system clean and valid.

This form tool is a composite of the Google Places API and our Address Validation International service.  The process consists of the data entry portion, the Google Paces API lookup, then the Address Validation International service call, finally displaying selectable results to the end user.

Let’s start by discussing the Google API Key, and then the form, and finally the methods required to make that Google Places API call.

Google Places API requires a key to access it.  You can learn more about this API here.  Depending on your purposes you may be able to get away with using only Google’s free API key but if you are going to be dealing with large volumes of data then the premium API key will be needed.  That doesn’t mean you can’t get started with the free version: we in fact use it to put our demos together, and it works quite well.

When setting up your key with Google, remember to also turn on the Google Maps Javascript API, or else calls to the Places API will fail.  Also, pay particular attention to the part about restricting access with the API key.  When you have a premium key this will be very important because it will allow you to set the level at which you want the key to be locked down, so that others can’t simply look at your Javascript code and use your key elsewhere.

The form we need to create will look like a standard address data entry form, but with some important details to note.  First let’s look at the country select box: we recommended that this be the first selection that the user makes. Choosing a country first benefits both you and the user, because it will limit suggested places to this country, and will also reduce the number of transactions against your Google Places API key.  Here is a link to how Google calculates its transaction totals.

Another important note is that we need to have the Apt/Suite data entry field.  As mentioned earlier, the Google Places API often does not return this level of resolution on an address, so we add this field for the information be provided by the end user.

The rest of the fields are really up to you in how you display them.  In our case, we display the parsed-out components of the results from selected address back into the rest of the address fields.  We keep all the address input fields editable so that the end user can make any final adjustments they want.

The methods associated with this process can be summarized by a set of initializations that happen in two places: first, when a country is selected, and second, when the focus is on the Address field by a user clicking into it.  For our purposes we default the country selection to the United States, however when the country is changed the Autocomplete gets reinitialized to the selected country. And when a user clicks into the Address field, the initialization creates a so-called bias, e.g. Autocomplete returns results based on the location of your browser.  For this functionality to work, the end user’s browser will ask to let Google know its location.  If the user does not permit Google to know this the suggestion is turned off and does not work.

This bias has a couple of interesting features.  For instance, you can change the code to not utilize the user’s browser location but instead supply a custom latitude and longitude.  In our example, the address suggestion does not end up using the user’s current position when the selected country is not in the same country as the user.  But when the user is in the same country as the selected country then the results returned by the Google Places API are prioritized to your location.  This means that if you are in Santa Barbara, CA and select the United States as the country, when you start typing a United States address you will first see matching addresses in Santa Barbara, and then work outward from there.

You can customize the form bias to any particular location that you have a latitude and longitude for.  The ability to change this bias is very useful in that setting the proper bias will reduce the number of lookups against the Google Places API before finding an address match, and will also save manual typing time.

Now let’s discuss the Address Validation International service API call, which consists of a key, the call to the service and setting up best practices for failover.

Let’s start with the key.  You will need to either have a live or free trial license key from us, the latter of which can be gotten here.  For this example, a trial key will work fine for exploring and tinkering with this integration.  One of the great things about using our service is that when you want to turn this into a live production-ready solution, all you have to do is switch out the key from the trial to the production key and switch the endpoint to the production URL, both of which can be done in minutes.

The call to the Address Validation International service will be made to either the trial or production endpoints, which will depend on the key that you are using.  The details of the service and how to integrate with it can be found in our developer guides.  In the Javascript code you will round up all the data in the fields that were populated by the address suggestion selection and send them off to the service for validation.  The code that manages the call to the Address Validation International service needs to be executed on some back-end server client.

It is strongly discouraged to make the call to the service directly from Javascript, because it will expose your license and allow someone to take it and use your transactions maliciously.  You can read more about those dangers here.  Also, here is a blog about how to make a call to another one of our services using a proxy.  The basic idea is that your Javascript call will call the proxy method that contains your license key, essentially hiding it from the public.  This proxy method will make the final call to the Address Validation International service, get the results from it and pass those results back to the original call in the Javascript.  In this situation, the best place to implement failover is in the proxy method.

So what is failover? Failover, from the perspective of an end user developer, is just a secondary data center to call in the unlikely event that one of our primary data centers go down or does not respond in a timely manner.  Our developer guides can again help with this topic.  There you will also find code snippets that demonstrate our best practice failover.

Once this call is set up, all that is left is evaluating the results and displaying the appropriate message back to the end user. While you can go through our developer guides to figure this out, the first important field to examine in the response from the Address Validation International service is the Status field – here is a table of what is expected to be returned:

Address Status

Name	Description
Invalid	For addresses where postal and/or street level data is available, and the street was not found, bad building number, etc.
InvalidFormat	For addresses where Postal data is unavailable and only the address format is known.
InvalidAmbiguous	For possibly valid addresses that may be correctable, but ultimately failed validation.
Valid	For addresses with postal level data that passed validation.
ValidInferred	For addresses where potentially far reaching corrections/changes were made to infer the return address.
ValidApproximate	For addresses where premise data is unavailable and interpolation was performed, such as Canadian addresses
ValidFormat	For addresses where Postal data is unavailable and only the address format is known.

 

Another important field will be the ResolutionLevel, which can be one of the three following values: Premise, Street and City.  The values returned in these two fields will help you make a decision in the code with respect to what exactly you want to display back to the end user.  What we do in our demo is display the Status and ResolutionLevel to the end user along with the resulting address.  Then we give the user a side-by-side view of both the resulting address just mentioned and the original address the user entered.  This way the end user can make a decision based on everything we found. In the case shown here, for example, we updated Scotland to Dunbartonshire and validated to the premise resolution level.

There are many customizations that can be made to this demo, such as the example we mentioned earlier about setting up the bias.  Additionally, instead of using the Address Validation International service you could also create an implementation of this demo using our Address Validation US or our Address Validation Canada products.

Want to try this out for yourself? Just contact one of our Account Executives to get the code for this demo – we’ll be glad to help.

Welcome to our third installment in our Salesforce Data Quality Tools Integration Series. In the first two parts, we covered creating a plug-in that could be dropped on a flow and a trigger. Today, we are going to jump into creating a VisualForce app that you’ll be able to extend for your purposes. At the end, you will have all the code you’ll need to get started, so don’t worry about implementing this step by step as I have it laid out in this blog.

The goal of this app is to display to a table of contacts that can be selected to have their emails validated. We will add a filter to the table to better target certain emails for validation. We will also display a few charts that will provide a good overview of the state of the emails in their system. These charts will refresh according to the filter selected for the table of contacts.

As always, we are going to start with some basic setup, then switching to look at what the final VisualForce page is going to look like, after that we’ll run through the code. During this walk-through, it should be clear where there are opportunities for customizing this solution.

The very first thing you need to start with is setting up the Service Objects endpoint. I am not going to go over it this time because I go over it in the first and second parts of this series. So, if you need help setting up your endpoint or a description of what this is, please check out the previous blogs. If you have been following along from the first two blogs, then you have already completed this part. Once you have set up your endpoint, you will need to add the following custom fields to the Contact object. If you are customizing this for your own purposes, you will want to add these fields to the object you are working with. If you want to map more of the fields that our service returns, you’ll have to create the appropriate fields on the object, if there isn’t an existing field already at your disposal.

• Field name
  • Internal Salesforce name
  • Type
  • Service Objects field name

• Email Catch All
  • EmailCatchAll__c
  • Text(20)
  • IsCatchAllDomain

• Email Score
  • Email_Score__c
  • Number(2,0)
  • Score

• Email Score Name
  • EmailScoreName__c
  • Text(20)
  • DPVNotesDesc

• Email Top Level Domain
  • EmailTopLevelDomain__c
  • Text(50)
  • TopLevelDomainDescription

Here is a view of the table with the filter and the Validate button.

Next is a screen shot of a couple of the charts.

As you can see, it is a pretty simple example that can be tailored to whatever custom solution you are looking for.

For this walk-through, we will be creating three files: one for the markup, one for the controller and one for the web service call.

MARKUP

Starting with the markup page, the actual VisualForce page, we will create a file called EmailValidation.vfp. For the first element, the Apex:page element, we define which controller we want to have associated to the page. We will make a custom controller for this app, “ContactEmailValidationController”, which is the name of the class that we will build later in the controller section. After we establish the controller that we are going to use, we override some styles so that we get the headers in the charts to stand out properly.

Next, we create the page block that will house the components to the page inside a form. The four main components are the filter, the table of contacts, the validate button(s) and the charts. You will more than likely want to implement a paging system for the table, so you can page through your contact records but I do not go into that here.

The filter section is basic:

Throughout the code you will see instances of values that come in the form of {! [Some variable name]}. That is simply a reference to a value in our custom controller. In the case of the filter, we have two of those instances, one for the filterId and one for Items. In this case, the filterId is telling the select dropdown list which item is selected. When the page first loads, nothing is selected, so the filterId is empty or null, which will render the default table view. You can certainly set this to have some other default value. The Items variable simply holds all the possible select options for the dropdown list. Items is populated in the controller, which we will take a look at later. Since we want the charts and the table to refresh when the filter is changed, we set the reRender attribute on the actionSupport element to target contacts_list. This is the id of the overarching page block section. Any markup outside of the contacts_list page block section will not be refreshed. The underlying code does an ajax call to refresh just a part of the page, which can be handy when you don’t want the whole page to reload.

In the next section of the markup, we setup the table of contacts and the columns that we will display back to the user. I have collapsed much of the code here so we can first focus on the apex:pageBlockTable element.

There are two things to notice in the page block table element. First, the contacts variable holds all the contacts coming back from the controller. Later, you will see a method on the controller that is called getContacts which is specifically named that way to sync up with this contacts variable. For example, if the variable was called people then the controller would need a method to retrieve those records called getPeople. The second thing to notice is the value cont for var. This value will be the container for each of the contacts in the contacts variable. The format and setup of the page block table element can be described such that it acts like your traditional for each loop. On a side note, there are many ways we could have created this table. For instance, we could have used a repeater or a couple of other elements to display the contacts to the user.

Next, we are going to look at the way we setup the columns and we’ll start with the checkbox column, since it is unique to the rest of them.

This column consists of an apex:facet and a checkbox input. The facet will implement its own checkbox input as well. We use the facet to customize the header of the column with a checkbox. Salesforce defines the facet as this “A placeholder for content that’s rendered in a specific part of the parent component, such as the header or footer of an <apex:dataTable>”. The checkbox in the header will act as the select all/select none functionality of the column. The checkboxes in the rows will be populated with a contact id so we can track which contacts were selected. The onclick functions in both input elements reference JavaScript functions that we will discuss in more detail shortly. Simply put, those functions will manage the storage of selected rows.

The columns I have highlighted with the red boxes are going to be your standard output columns and those outside of the red boxes will need the header label, for the respective columns, updated to be more readable.

Earlier we created the custom fields to house some of the values that will be coming back from the call to the email validation service. Creating custom fields can, at times, lead to having to create a more “technical” label for the field instead of “displayable”. One obvious reason is so new custom fields do not conflict with existing fields or any future fields. Keeping that in mind, we do not want to use the labels of a couple of our custom fields in the header, so we will update them using the facet like we did earlier for the checkbox header but this time without a checkbox.

In this simple example, we are updating the header text, but the values in the column will still be pulled from the cont.EmailTopLevelDomain__c variable. And that is really it for the columns, pretty straightforward. And easy to extend, with little effort you can alter this example to display any of the columns you want in the table, as long as you have access to them from the controller.

In the next section, we will focus on the pie charts. The sample code will have a chart for Email Scores, Catch All Domains and Top Level Domains. The code becomes redundant, so I will only demonstrate one of them here. With that said, you can add any chart you want that focuses on the particular situation you are solving for. The overarching chart container is a page block element that I titled “Email Details”. This will house the three charts.

Each pie chart is wrapped in a page block section with it’s own unique title. For the apex:chart element, we see the variable EmailScorePieData. That links up to the getEmailScorePieData method on the controller which pulls in a list of wedgeName and count combinations which we can see referenced in the apex:pieSeries element.

Next, we’ll jump into the JavaScript portion of the client code. The JavaScript code on the markup page was designed to handle the checkboxes and compiling a list of ids based on checked/unchecked boxes. I used the code from this source on the internet. My only contribution to the code was to update some of the variable names to match more of what was going on in it. As you can see there is a function for selecting/deselecting one or all checkboxes at a time.

I am not going to take a deep dive into this code, since reading through it should illustrate what is going on there. At this point, all you need to know is that it compiles a list of Contact ids into the ContactIdBuilder variable based on which boxes have been checked as I mentioned earlier.

I did skip over the last part of the markup because it would be easier to make the connection between the ContactIdBuilder variable and the following markup code.

This part of the code, when the Validate button is clicked, it takes the id list stored in ContactIdBuilder and assigns it to the returnString hidden input element. After the value is assigned, the ValidateCheckedEmails method on the controller is called. The returnString value associates to the returnString variable in the controller that we will see shortly. And that is it. That’s all for the user facing part of the code.

CONTROLLER

The controller code consists of two main parts. First, getting data from Salesforce and displaying it to the screen. And the second part is validating the selected rows from the user interface.

Based on the filter selected from the user interface, the getContacts method will return a list of contacts. The main thing that you need to do here is make sure you are pulling back all the fields that the user interface needs to work with, taking into account both the visible and hidden fields. For example, the contact id which is in the background on the checkbox columns.

The method, getItems, retrieves all the filter options for the dropdown list in the user interface. In this method, we put together a list of hardcoded options and then some dynamic options that will allow us to filter on each company in the list.

The three methods that get the data for the charts return a list of EmailData records which are simply key/value pairs. Key being the name of the pie wedge and value being the count or size of the wedge. You can use the pie methods here to copy or modify to suit your own purposes. The more stats you want to present to the user, the more fields you’ll need to retain from the call to our email validation web service. Some of the other fields you may be interested in adding here are, the warning notes, the notes descriptions and/or the SMTP flags (server and mailbox level). There are many other fields that our email validation service returns and you can look at them in more depth here.

The last part of the controller to go over is the call to the method that does the email validate request. The method ValidateCheckedEmails pulls all the contact ids from the returnString variable and sets them up for processing in the CallEV3ByIdList method of the EmailValidationUtil class.

WEB SERVICE CALL

The EmailValidationUtil.apxc is the last file left to discuss. This file does the actual request to the email validation web service. This is the part of the code that you can customize the most; from what you decide to process to what is returned by the service. It is also a good place for any additional logic you may want to implement.

This code should seem very familiar to you if you had read the previous parts of this blog series. It is setup in a very similar way. Just as with the other examples in this blog series, we demonstrate the best practices when it comes to implementing failover. The inputs to the service are the EmailAddress, AllowCorrections, Timeout and Licensekey.

In our example, the email address comes from the contact records selected in the user interface and the rest of the inputs are hardcoded (but they don’t have to be). AllowCorrections accepts true or false. The service will attempt to correct an email address if set to true. Otherwise, the email address will be left unaltered if set to false. Here, I hardcoded it to true but you may want it to be false or use some other business logic to make that determination. The Timeout value specifies how long the service is allowed to wait for all real-time network level checks to finish. Real-time checks consist primarily of DNS and SMTP level verification. Timeout time is in milliseconds. A minimum value of 200ms is required. I have hardcoded it to 2000ms. For the LicenseKey, you will want to either hardcode this into the call (depending on the access that people have to the code) or create a custom object and/or a custom field with the license key that you can lock down with user permission only available to the administrator.

Before I wrap this up I wanted to make mention of writing tests to cover the code. This example is complete but expects you to customize parts of it, so I have not provided any test code. You will want to do that. It will ensure that even as Salesforce updates their system or you make changes to your organization, everything will continue to work as expected.

In conclusion, VisualForce pages are mostly used with the old Salesforce UI the Classic UI, but it can be created in a way so that it will continue to work with the new Lightning experience. In a future blog, I will show a demonstration of how to create a Lightning App while incorporating our validation services. Service Objects has validation services for all kinds of solutions, making Salesforce a perfect platform to demonstrate our services on.

Many developers come to Service Objects because they recognize their company has a need for a data quality solution. Maybe you were tasked by a manager to help find a solution, perhaps someone in Marketing mentioned one of their pain points, or maybe you just naturally saw opportunities for improvement. Whatever the reason was that got you looking for a data quality solution, you most likely need to get someone in management to sign off on your solution. Often, especially in larger organizations, this can be a challenge. So how are others accomplishing this?

Service Objects has been in business for over 16 years and in that time frame, we have helped potential customers just like you get sign off for our services. In addition to being armed with information from your Account Executive on how you can achieve ROI for the service you have chosen, the following recommendations are the ones we have found to be the most useful.

Test Out Our Services

If you haven’t already, get a free trial key for the service you are interested in.  We allow you to try out as many of our 23 data quality solutions as you would like.  My blog, Taking Service Objects for a Test Drive, can help you figure out which method of testing our services is best for you.

One of the values in testing our services is that it reinforces your own understanding of our products. Testing allows you to quickly visualize and show others in your organization the benefits of utilizing a data quality solution.  Showing your boss an actual test integration you did with our API is more powerful than just explaining how it works.  Or, if you decide to run a test batch with us, you will see first hand how we can improve your contact data.

You can also leverage our quick look up page and set up on a screen share with a larger team and run live examples for them.  Let your team choose some data to run live and see the results first hand.

Data Summaries

Data summaries are a great visual aid to take a look at how our services help.  Take a subset of any of your data sets and send them over for a batch test.  Each batch test contains a comprehensive summary, providing you with how we validated your data and what the results mean.  Your Account Executive can review this and guide you through the results. Having a detailed report that clearly shows the current state of your data is a great tool to have when you are ready to go forward with any type of presentation to your team. A recent blog shows what one of our reports includes.  All data has a story, and with our batch summaries we try to tell that story.

Integration Plan

Having an integration plan is an asset when getting sign off for our services.  You are bound to get some questions after showing your plan, such as “who?” “how?” and “how long?”.  It is a good idea to be prepared to answer these questions.

Integrating with us is not a complicated task and we have several resources to guide you.  Our sample code can quickly get you up and running and we can even customize it for your specific use case. We also have best practices available to help you with your integration. For instance, you may need to check if there are any network or firewall issues your IT team needs to complete. If you are switching from another solution or vendor, you may need to have your integration timeline in sync with turning off an old service and turning our service on.  And never forget about testing, which is one of the most important parts of any integration.  Finally, you may need to account for any training you want to provide to your team about how to work with our data or your new system.  Having answers to these questions can help arm you with everything you need to keep the ball rolling.

Customer Service and Support

Support.  It is just one word but it is key.  Sometimes even the most important word.  You can purchase a top-notch product or service, but if you can’t get adequate customer support when you need it, your purchase loses most of its value to you.  With Service Objects, this is never the case.  In fact, customer service is one of our core values. We care about your success and truly want you to be succeed.  If you want to get buy in from your team, then it is very important to discuss our customer service expertise. Having a dedicated customer support resource, comprised of engineers, will ease your transition to our offerings and in the end, will save your organization significant time and money.

Value Proposition

At Service Objects, our value proposition is very clear. Our data quality solutions ensure your data is as genuine, accurate and up-to-date as it can possibly be. A large percentage of our customers have been with us for many years, and this is due to the effort we put into the quality, accuracy, speed, reliability and expertise we deliver.

Getting Buy-In from Colleagues

It is always helpful to get people on your side when you want to present a new service to your company. Talking it over with colleagues and managers is great and many of the things written in this blog can help get them on your side to support your idea.  It also goes a long way in educating your team on the data quality issues you are facing and how a Service Objects’ solution can alleviate many of those problems.

I hope some of these ideas or tips can help you along the way in presenting our services to your team or manager.  The last thing you want to do is have a conversation with your boss without adequate preparation.  Your ideas are good, so take your time and plan the right action in getting them implemented.  In the end, the results our services will provide for your company will be impactful and worth your time.

Visit our product page to Get started testing any of our services.

Welcome back to our blog series where we demonstrate the various ways you can achieve high data quality in Salesforce through the use of Service Objects’ validation tools.

In the first part of this series, we showed how to create a trigger and an Apex future class to handle calls to our web service API. That blog described a common way, in code, to call our services in Salesforce. But, there are more simple ways to do this.

In this blog, we are going to step back and demonstrate an integration that requires little more than drag and drop to achieve your goals by implementing a plug-in on a flow. Because – why write code if you don’t have to? When we are done you will be able to create a flow and drop our plug-in anywhere in your process and wire it up.

We are going to start by looking at some basic setup. Then we will step through the code. What code? You are probably wondering, “Why do we need to look at the code, if we don’t need to write any”. Well, if you wanted to implement any additional business logic or tailor the plug-in, you will be equipped to do just that.

After we review the code, we will jump into creating a sample flow that allows a user to enter either a US address or Canadian address and process that data through our US and Canada validation APIs and then display those results back to the screen.

In this section, we will need to do some setup before we get started. We will need to register the Service Objects’ endpoint with Salesforce so that we can make the web service calls to the address validation API’s. We went over this in the previous blog but it is worth repeating here.

The page where we add the URL is called “Remote Site Settings” and can be found in Home->Settings->Security->Remote Site Settings. This is the line I added for this blog.

Be aware that this will only work for trial keys. With a live/production key you will want to add a URL for for ws.serviceobjects.com and wsbackup.serviceobjects.com. As a best practice, you’ll want to add both endpoints with your live key, to take advantage of our fail-over capabilities. We named this one ServiceObjectsAV3 because we are really just reusing it from the previous blog but you can name it whatever you want.

No need for custom fields to get this example to work but you will likely want to create the same ones or similar as those in the previous blog, seen here.

This section shows the structure of the plug-in class for the US address validation, that we are naming AddressValidationUSA3, and the signature of the invoke and describe methods. The invoke method will contain the business logic and the call to our web service API. The describe method sets up the input and output variables for the plug-in that end users will be able to connect to on a flow.

The describe method also allows you to supply definitions and descriptions of the variables on the plug-in itself that will appear in the flow interface. The definitions used here are important because it can save a lot of time for the end user that is developing a flow. I would resist skipping this to save time. The following is just a snippet of the code.

There really isn’t much else to the describe method, most of the business logic happens in the invoke method. In the invoke method, we will gather the inputs to the plug-in and do some initial formatting to make sure we have valid characters in the call to our API. In gathering the inputs, we make sure to use the names of the inputs that we used in the describe method.

Since we will be making a path parameters call to the API, we want to account for anything that could break the URL like missing parameters. A missing parameter using our API should break the call but on other APIs it could simply change the meaning of the call and end up returning unexpected results. To make sure there are no issues with missing parameters, we simply replace any ones that are missing with space character. Just as in the previous blog, there will be minimum field requirements before it even makes sense to call the operation. The operation we are using is GetBestMatches and these are the requirements.

• Combination 1
  • Address
  • City
  • State
• Combination 2
  • Address
  • Zip code

If you do not have some combination of these inputs then it is best to add code to avoid the call completely, since there is no way to validate an address otherwise. By “avoid the call,” we mean avoid even hitting the plug-in at all, since it would not be necessary. A decision component in a flow can help with the process.

In an effort to simplify the code, I pushed the logic for calling our API into a method called CallServiceObjectsAPI which should make things easier to read. Using this method, we pass in the input parameters that we cleaned up.

Below, I show how to setup the HttpRequest/HttpResponse and the request URL. After that, I add in some basic error checking to check for a couple results. First, I am checking to see if there was an error with the API call and/or the result from it. If other errors happen outside of that then we catch the general exception, which I would assume is a connectivity issue at that point. You can try to catch more specific exceptions on your own but what I have here will work in a general fashion. In the instance of an error or exception on the call to our API, we also demonstrate our standard best practice of failover by adding code to call another endpoint in these situations. In the case of this blog, we are walking you through a trial key scenario, so failover in this case will not be true failover since it is failing over to the same trial.serviceobjects.com endpoint. But in a live key scenario, you would be encouraged to use ws.serviceobjects.com for the first call and wsbackup.serviceobjects.com for the failover call.

Another thing you may have noticed in the code above is that the input parameters to the API call are URL encoded and “+” are switched to “%20”. The reason for this is that certain characters are not allowed in a URL or a path parameters call, so the built-in Apex function urlEncode cleans that kind of thing up. One side effect that the encoding has is it replaces spaces with “+” symbols. Though in a URL “+” symbols are becoming the norm, path parameter calls still have issues with them. So the proper way to make the call work is to replace the “+” symbol with a “%20” which will be deciphered correctly as a space in the end. The method returns a string response from the web service and based on the call made, it is more precisely returning a JSON string response which we save in the variable ServiceObjectsResult.

The first thing we do after we get the response from the method is deserialize it into a Map object so we can start processing the result. Here is the rest of the code.

This section of the code is checking to see the type of response that was returned. The response could have been either an address, error or network error response. Based on those variations, we populated the corresponding output values in Map variable called “result”. In the Map, we map the outputs from the service to the expected outputs described in the describe method. Those values are the output values of the plug-in and are directly interfaced with in the flow. Adding code anywhere in the method we just went through would be appropriate based on your own specialized business logic.

Now that we have gone over the code, we are ready to jump in and show an example of our plug-in in a flow. For this example, I also created a Canadian address validation plug-in to make it a little more interesting. However, I do not see any service we offer that would not make for an appropriate and powerful example.

As I mentioned on the outset of this blog, I will show you a demonstration of a flow where the end user will be presented with a data entry screen. They will have options for adding either a US address or a Canadian address. From there, we will wire it up to either the US address validation plug-in or the Canadian address validation plug-in and then finally display the results to the screen. This flow will be more of an example on how to wire up the plug-ins rather than creating an input and output screen. Though doing something with screens is not out of the question, it will be more realistic to have a flow that manipulates Contact, Account or Custom objects without an interface.

Start by creating a new flow in the Process Automation section. I am just going to open the one I already had saved. Dragging on the Screen object is the first step and be sure to set it to be the starting interface by setting the green down arrow on the object. A flow cannot be saved without one part of it being a starting point.

Inside this interface you will setup the input fields that you want to retrieve from the user. In this example, we forced the Address 1 field to be a required field and at the bottom we added a radio button selection for the desired country, defaulted to USA.

Once we have the inputs from the user, we need to find some way to route the variables to either a US address validation or a Canadian address validation. For that we can use Decision Logic Tool. We will configure it to look at the country field and make a decision on which way it should continue to process.

The actual logic simply decides to go down the US address validation path if USA is found otherwise it will assume it is a Canadian input address.

Now we are ready to drop our US and Canada address validation plug-ins on the screen. On the left, in the Tool area you can find the plug-ins under the respective names you gave them in the creation of the plug-in.

You can and will be forced to drag them onto the flow canvas one by one and set them up individually. Inside you will be mapping the inputs from the user data entry to the inputs for the plug-ins. Additionally, you will be mapping the outputs to variables you create or objects variables in the system. This can take some time depending on how many of the address validation outputs you want/need to use.

When you are done with that part, you will wire them up in the flow to the decision tool you added earlier as shown below.

In this last part, we will setup two output screens, one for the US address validation results and one for the Canadian address validation results. This time instead of adding text boxes to the interface, we just add a display object for each field we want to show.

After wiring the last screens, the completed flow will look like this.

From here you can choose to save the flow and then add layout options on other screens that will give you access to executing the flow, schedule the work flow to run at a specific time (not useful in our example though) or you can run it directly from this interface by clicking Run. We will demonstrate it by clicking Run. We’ll start with a US address and then view the results on the output screen. In this example, you can see there are several issues with this address. Street name is incomplete, it uses unit instead of suite, city name is misspelled and even the postal code is wrong.

Upon validation, we see that the system was able to correct the address and had a DPV score of 1 meaning the result is a perfect address. The DPV score is one of the most important fields to pay attention to in the output. It indicates the validity level of the address. You’ll see other information in the response that will give you an idea about what was changed or if there were any errors. You’ll also have access to the fragments of the address so you can process the response at a more granular level. More details about the fields can be found here.

In the last example, we will use a Canadian address. In this case the only thing wrong with the address is the postal code, so we’ll see how the system handles that.

Sure enough that address validated and the postal code was corrected. In the US address validation service, the DPV score and error result indicated the validity of an address. In the Canadian validation service, we really only need to look at the error fields. Empty or blank error fields will mean that the address is good and can receive mail.

In conclusion, we learned how to create a plug-in and then use it in a flow. Though you do not need to know how the plug-in was made to be able to use them, it is very helpful to know the details in the case that your business logic requires a more tailored solution. And you can see that in this demonstration adding additional code does not take much effort. These plug-ins allow you to get up and running very quickly without needing to know how to code. As I mentioned earlier, the flow created here is definitely a use case but more often than not I would imagine Salesforce administrators creating flows to work on their existing objects such as Contact, Account or some other custom object.

A quick note on the license key, you will want to add you own license key to the code. You can get one free here for US address validation and here for Canadian address validation (Each service will require a different license key).

The last thing I want to discuss about the license key is that it is good practice to not hard code the key into the code. I would suggest creating a custom object in Salesforce with a key field. Then restrict the permissions on the field so that it is not view-able by just anyone. This will help protect your key from unwanted usage or theft. At this point, we have the code for these two address validation plug-ins, but Service Objects will continue to flush out more for our other services and operations. With that said, if there is one you would like to request, please let us know by filling out the form here and describe the plug-in you are looking for.