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.

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.

Salesforce is a great CRM that allows businesses to easily put customers at the center of their attention. But even a tool like Salesforce can be halted by poor quality customer data. Well, luckily for businesses and their data, Salesforce allows its users to call outside APIs and web services like our data validation services. If this is something that you haven’t done before, it can be a bit tricky; but don’t worry! The integration specialists here at Service Objects have you covered and we can show you how to get up and running in Salesforce in no time!

Remote Site Settings

One of the first things you will want to do to get your data validated is to add the Service Objects domain as an allowed site to access from within Salesforce. To do this, log into your Salesforce account and enter “Remote” in the Quick Find search bar as shown below.

Select “Remote Site Settings” and you will be taken to a page that lists all of the external sites that you can access from within Salesforce. Select “New Remote Site” and enter the information as shown below.

Once you click “Save” you will be ready to validate your data through a Service Objects web service. You should also add the site wsbackup.serviceobjects.com to the list of remote site settings as this will allow the ability to integrate proper failover configuration into your application.

SOAP vs. REST

If you are using REST to access a Service Objects web service, then you are good to start validating data. You simply have to make the HTTP call to one of our web services and then decide how you want to implement your newly validated data.

If you happen to be using SOAP to connect to our services, then you will have to alter the WSDL you use to connect to our services. A WSDL is a machine-readable document that tells a platform and coding language how to connect and interact with a web service. In order to do this, a bit of the WSDL will need to be altered. Lucky for you, we have already done this! We have a flight of updated WSDLs, Apex code examples, and handy guides for each of our services that will help you get up and running in Salesforce in no time.

To upload the edited WSDL, select the “Develop” link under the “Build” heading on the left-hand side of the main screen. Then select “Manage Apex Classes”.

On this screen, you can select the “Generate from WSDL” button and then choose the updated WSDL to upload to Salesforce. If the WSDL has been properly edited then all the necessary classes will be successfully created and you can begin accessing Service Objects web services through Salesforce.

Your data is now ready to be validated! Once you have ensured the integrity of your customer data, you can get back to using Salesforce to guarantee the best interactions possible with your customers!

Also, be sure to check out our Free Salesforce Chrome Extension for a quick and easy validation tool to use in your browser!

Having validated and standardized addresses within your CRM will improve business efficiency, cut down on bogus leads, and help reduce waste. Let our new DOTS Address Validation Chrome Extension for Salesforce do all of the validating and standardizing for you.

Configuration is as simple as copy and pasting your license key into the key field on the options page after downloading the extension:

From there, any time you are on a Lead, Account, or Contact page within Salesforce, right clicking will present you with an option to validate the address. The extension will automatically pull out the address, city, state, and zip code, thus eliminating the need to manually enter the information you wish to validate. User error is taken out of the equation so you can be sure the address in your CRM is the address that is being validated. After validation, updating your Salesforce Lead/Account/Contact address is as simple as clicking an update button:

The Technologies at Play

DOTS Address Validation – US 3

Our USPS CASS Certified™ DOTS Address Validation service improves internal mail processes and delivery rates by standardizing contact records against USPS data and flagging for vacancy, addresses returning mail, and general delivery addresses. Our industry-leading GetBestMatches operation, now combines Delivery Point Validation (DPV), SuiteLink and Residential Delivery Indicator (RDI) into one robust API call to our USPS CASS Certified™ database engine.

Addresses are pulled from the Salesforce Leads, Accounts, or Contacts tabs and then validated through the DOTS Address Validation – US 3 service. Once the address is validated, a window will pop up showing the service’s results. If the address was standardized and corrected to a perfectly deliverable address (DPV1) an option is given to the client to automatically update the address in their Salesforce instance.

Google Chrome Extensions JavaScript API

This is the primary technology that allows this project to be possible. The JavaScript API that is provided by Google allows developers access to the inner workings of the Chrome browser giving them access to features such as browser actions, events, web requests, and more. Developers are able to add functionality to the Chrome browser while staying lightweight and nonintrusive.

Installation, Configuration, and Usage

Please refer to our website for a detailed breakdown on installation, configuration, and usage for the Chrome extension for Salesforce.

You’ve heard of all the benefits of contact validation, but yet something’s holding you back. Whether you’re unsure about how to implement contact validation with your existing systems or concerned about the potential cost, rest assured, it’s easier to succeed with contact validation than you might think. Here’s why:

Various contact validation APIs are readily available.

The type of data you can validate with contact validation software includes everything from names, addresses, phone numbers, and email addresses to credit card BIN numbers and demographic data and more. Whether you need to pinpoint the exact physical location of your customers for accurate deliveries, would like to learn more about your customers, want to reduce your mailing costs, or want to validate transactional data for signs of fraud, there’s a contact validation product that can do it.

APIs are easy to integrate into existing systems and web forms as well as third party software such as Salesforce.com, Oracle DB, and Drupal UberCart.

For example, Service Objects APIs work with most common web form types including Java, PHP, .NET, and others. Sample code is provided for many programming languages. In addition, Service Objects has a team of experienced engineers who are happy to help guide you through the XML integration process. If you use SalesForce.com, Oracle DB, Microsoft CRM 2011, Microsoft Office, Microsoft SQL Server, or Drupal UberCart, integrating contact validation into your existing solution is a simple matter of installing a plugin; there’s no programming required.

You can get up to 500 free API test validations to try before you buy.

If you’re not sure that contact validation is right for your organization, one way to find out for sure is to try it for yourself. Service Objects offers a free trial key for each of its contact validation APIs, allowing you to validate up to 500 contacts before making a decision.

Once configured, contact validation happens in real-time.

The hardest part is deciding to embrace contact validation and implement a real-time contact validation solution, and that’s really not all that difficult. From there, your contacts will be validated at the point of entry. You’ll never send another expensive mailer to “Homer Simpson” at 123 Main Street again because the API will recognize that name and address as bogus the moment it’s entered.

Contact validation quickly pays for itself.

Contact validation has a fantastic ROI. For example, if 15 percent of the addresses in your mailing list are undeliverable and you mail 10,000 letters a month, you’d be paying for supplies and postage for 1,500 letters each month. Assuming you’re paying 44 cents in postage, that’s at least $660 each month in wasted postage. Contact validation can also reduce fraud, improve deliveries, and improve productivity, all of which have a positive effect on your bottom line.

Finally, Service Objects includes its “Customer Success Program” with its annual contracts. Dedicated account support, engineering and application support, courtesy testing keys, and a 24/7 emergency response work together to ensure your contact validation success! So what are you waiting for? Start your free trial today and see for yourself just how easy it is to succeed with contact validation! 

 

Introducing the Address Validation
Do-it-Yourself Plugin for Salesforce.com

When I can get greater functionality out of my work applications without getting the tech staff involved, it makes my day. Sometimes I just need a no-muss-no-fuss solution that doesn’t require me to fill out a time and expense requisition for help. There are also times I need things done quicker than professional business manners allows for. I wouldn’t want my co-workers to confuse my enthusiasm with pushiness, after all.

I think Service Objects’ development team had people like me in mind when they came up with this new plugin for Salesforce.com. It’s so easy to install that everyone with basic computer skills can do it,  and immediately start validating contact addresses, in real time, from within their Salesforce.com applications— regardless of technical background and without breaking a sweat.

Prior to the development of this plugin, implementing Address validation services required programmers with advanced programming skills, familiarity with various technologies like XML, SOAP, and web services and an understanding of Salesforce.com’s development platform as well as their proprietary programming language.

Today, no programming time or expertise is required. If you’re working in Salesforce.com and want to start validating your contact addresses immediately, then you’ve got to try out this Address Validation plugin.

To use our web services, you’ll need to sign up for a free evaluation Trial Key or purchase a Production Key for DOTS Address Validation. Use your own data with our Address validation services to compare and correct your data entries with USPS and Canada Post database information.

Download our easy 12 step installation guide and see for yourself how easy it is to install.