StrikeIron Blog

Salesforce.com Only as Good as the Data Within it: StrikeIron Web Services Now Fully Integrated, Including Custom Field Mappings and Batch Processing

Since the beginning of contact management applications, the effectiveness of CRM has always been dependent on the quality and comprehensiveness of the data within the CRM system's database. The better the data inside, the better the ROI.

Incomplete or inaccurately collected data can cancel out any productivity gains CRM might provide if a sales team is spending a great deal of time tracking down correct information about a prospect, or spending time chasing down prospects who are difficult to find or no longer employed by the organization being pursued.

In addition, enhancing the existing, basic data that exists within CRM systems with additional data points about a prospect can enable all kinds of processes such as lead scoring, segmentation, lead nurturing, business intelligence, and other data-driven activities that can greatly increase CRM ROI, and therefore provide a greater amount of success to the organization that leverages these processes.

Salesforce.com is no different. Its Software-as-a-Service paradigm change still is just as reliant on the actual CRM data within it for success as its precursor enterprise software solutions.

StrikeIron is aiding significantly in this cause to provide a much more effective Salesforce.com experience as a result of better, more complete data within the system. Using Force.com, we have natively integrated several of our data quality and data enrichment Web services seamlessly into the Salesforce.com environment. We have provided a very simple way to map Salesforce.com fields, including custom fields, to an organization's Salesforce.com instance, enhancing and verifying data record by record.

Now, this also includes batch processing, meaning with a few clicks, the quality and comprehensiveness of the entire Salesforce.com database can be substantially increased.

With the following screen shots, you can see how easy it is to map fields from a Salesforce.com instance to fields matching StrikeIron Web services that are currently in 24x7 production use with thousands of different organizations worldwide who are currently leveraging external data in real-time across the Web for a broad range of applications.

Once set up with the simple configuration tool, the entire process of invoking StrikeIron Web services using data within the Salesforce.com system to validate and enhance that data is then completely automated from that point forward.

The following steps demonstrate how quickly and simply the StrikeIron Salesforce.com application can be configured to achieve better data within Salesforce.com:

Step 1 - Set up your StrikeIron authentication information. This information will be used to authenticate with StrikeIron servers when the data is being checked and enhanced during processing. You can get a StrikeIron UserID and Password simply by registering at our Web site or contacting one of our account managers.

Step 2 - Provide your Salesforce.com authentication information and the query string for batch processing (we can help you set this up, but it's a pretty basic query to determine which records will be verified and enhanced if a subset is desired).

Step 3 - Map which fields within Salesforce.com will be used as input parameters to the StrikeIron Web service. This is the data that will be verified and/or enhanced and will be used as the lookup keys to the data sources that we constantly update on our servers.

Step 4 - Select the Salesforce.com fields (any fields, including custom created fields) from which the response data will be mapped to and inserted into the Salesforce.com database for each record.

Step 5 - Set up any necessary or desired options.

Step 6 - Begin processing and watch it work!

As you can see, it is now quite straight-forward and quick to perform mass verification and data enhancement processes within Salesforce.com, providing better data, leading to a more efficient and effective sales team, and therefore better ROI with your Salesforce.com investment.

Delivery Point Validation (DPV) Versus a CASS-style Address Validation

When customers are using our address verification capabilities via a Web service API within their applications and Web sites, they often ask what the difference is between an "address validation" and a "delivery point validation."

The ability to determine both exists within our product offering, but there is often confusion concerning the difference between the two and where and why the distinctions are useful. So let me try to explain.

In the case of "address validation" and whether or not an address is "valid", this refers to the CASS-certification-related style of determining the validity of an address according to the United States Postal Service master database (typically employed to gain postal discounts). However, this particular database only contains ranges of valid addresses for a given zip+4 location rather than a listing of actual physical addresses.

In other words, if you are trying to validate an address of "500 Broad Street, Anywhere, USA  12345", the database will contain entries of the ranges of that street in that particular city, and if the address to be validated falls within that range of valid street numbers, an address will be considered valid. This is without consideration as to whether or not that specific address physically exists and mail can be delivered to it. There could be a "490" Broad Street, a "496", and then a "504", but no "500". However, because it falls within a valid range, it will be returned as "valid."

This is where "delivery point validation" comes in (also known as DPV). During the address validation process, if the DPV flag is set to Y (because it exists in the DPV database), then this means that this particular address does indeed physically exist and mail can be delivered to it. This is a more granular indicator.

Here is an example of the two approaches. In the first, "500 Broad Street" would be determined a valid address:

In the second, the DPV indicator for this particular address would be returned as "N" since the address does not exist within the delivery point database:

So while a CASS-certified style of address verification is useful and effective in a broad set of business cases, what this demonstrates is that in terms of saving postage on undeliverable addresses and address quality in general, the DPV indicator, with its database containing over 145 million verified delivery points in the USA and its territories, is a more effective means of determining the existence of a given address.