Address Validation in Salesforce – Implementation Options and Considerations
No matter if Salesforce is used only for opportunity tracking or for more advanced functions like marketing automation, traditional mailing, service management or billing, sooner or later having an accurate address database becomes important.
Furthermore, in most organizations customer records are initially created in the CRM as leads and opportunities. The earlier this data is validated, the lower the risk of propagating inaccurate information to other systems, such as customer care, billing, and beyond.
This post explores Salesforce address validation, along with various implementation options and key considerations to ensure data accuracy.
Understanding Address Validation Process
Before diving into the details, it’s important to first understand how Salesforce address validation actually works.
The key point to remember is that address validation does not take place within Salesforce itself, but rather in an external service. Address databases are huge, specialized, and require a lot of software infrastructure, and run as cloud-based services with their own computing resources, storage, etc.
This applies to all major address validation providers, such as Google Maps, USPS, SmartyStreets, Yahoo and others.
Salesforce users don’t interact with these validation services directly. Instead, they access them through an add-on or custom-developed code that integrates with the Salesforce user interface, adds validation buttons and provides out-of-the-box validation for standard Salesforce objects like accounts.
The entire process can be visualized as follows:
Salesforce → Address Validation Add-On → REST or SOAP call → Validation Service
Selecting Address Validation Provider
Knowing how the validation works, making the right choice boils down to answering the following questions:
- Which address validation service to use (free vs. commercial, which provider, service plan, etc.)?
- Which add-on to use (a wide selection of commercial and free add-ons is available on Salesforce AppExchange)?
- Is any custom development required? For complex scenarios, it might be better to build custom code (i.e., interfacing directly with the validation service rather than an off-the-shelf add-on).
- What types of addresses are to be validated: domestic, international or both?
- What are the addresses used for: shipments, mailing, geocoding?
- Will they be used with map services?
- Is additional information required to be returned for an address such as county, telecom LATA, etc.
- Are there any preferred industry standards?
Popular Address Validation Services
The most popular address validation services are USPS (United States Postal Service), SmartyStreets and Google Maps.
USPS
A good entry-level service, especially if validated addresses are to be used for shipping:
- Optimized for mailing and shipping,
- Zip+4 precision,
- Free (register and use),
- No international addresses (U.S. and Canada only),
- Somewhat convoluted documentation (https://www.usps.com/business/web-tools-apis/general-api-developer-guide.htm).
Smarty (f.k.a. SmartyStreets)
A robust, commercial service:
- Good documentation (including on-line API testing), supported by multiple Salesforce add-ons,
- Full and partial validation,
- Zip+4 precision along with a lot of additional information (county, FIPS, geocoding and others),
- Support for bulk validation and autocomplete,
- Support for international address validation (requires additional subscription plan).
Google Maps
Address validation is a part of Google Maps Geocoding API. Compared to SmartyStreets or USPS, Google is focused on showing addresses on maps and business advertising.
Other Options
QAS (currently Experian) or Loqate (formerly PCA Predict/Postcode Anywhere) should be considered international addresses.
Specialized packages tailored to specific industry verticals, such as telecommunications quoting systems, often include their own address validation APIs, which can be an excellent choice for applications within those industries.
Other Considerations
Apart from the validation itself, practical use-cases also need to take into consideration additional items like standardization, bulk operations and others.
Address Standardization
It makes sense to implement data standardization before validation.
User entry → Standardization → Validation
In essence, standardization enforces that consistent names are used for various address parts (e.g., United States, USA, U.S.A.).
Most address validation tools will standardize an address anyway, however if standardization is enforced up front, there will be fewer validation errors down the line.
Multiple address standardization tools are available on Salesforce AppExchange, such as this one.
Important When using address standardization, make sure that standardization conventions match address input format expected later by the address validation tool. |
Background Validation
While address validation can be done in the background by Salesforce batch jobs, it is often an interactive process. For example:
- Address is incomplete and requires providing missing part, often looking at data outside the CRM such as paperwork.
- Address is ambiguous 1300 Main St. which can be 1300 N Main St. or 1300 S Main St.
Since each address validation may have an associated cost, it’s important to come up with a strategy that prevents re-validation of failed addresses without a prior review.
Bulk Imports
Legacy data migrated to Salesforce often includes addresses. In such a case, a decision needs to be made whether to validate addresses before or after importing.
We strongly recommend importing pre-validated addresses:
- Data migration usually takes place in multiple iterations, re-validating addresses many times will generate additional cost.
- Automated/background validation does not always work (see above) without user intervention.
Address Completion
For improved usability, it is often preferable to suggest addresses to users as they type them, rather than rely on post-entry validation. This approach, known as “Address Completion,” is more user-friendly and significantly reduces errors, as users select pre-validated addresses during entry.
Address validation providers typically offer a separate address completion API to complement their validation APIs. These completion APIs often come with separate endpoints and distinct pricing plans.
Custom Implementations
Occasionally, developing custom integration may be preferable to using off-the-shelf add-ons. Typical reasons for that include:
- Validation of addresses associated to custom objects.
- Background bulk validation.
- Need for custom user interface components making calls to address validation services.
In that case it’s probably worthwhile to start from scratch. Interfacing with validation services is not difficult from the technical standpoint, most development time is usually spent in APEX & Lightning not handling the API calls.
Publicly available resources, like this USPS integration on GitHub (https://github.com/colemab/SFDC_USPS-Component), can help you get started quickly.
Licensing
Most address validation services require a registration and obtaining an organization id that is later passed to validation service API. From a developer standpoint it is as easy as that, however, always make sure that whatever is done is compliant with service terms & conditions. These are usually published online and update very often, so make sure to read the latest version.
Conclusions
Address validation in Salesforce is an issue that eventually arises for most organizations. Fortunately, there are numerous implementation options available. The primary challenge often lies in selecting the right provider rather than in the technical aspects of the implementation. For instance, Nextian’s products support both Smarty and USPS, allowing customers the flexibility to choose their preferred provider.
Contact us today to find out how we can help you!