Getting starting with Geocodes in Salesforce

In Summer 16 release Salesforce has provided additional support for mapping addresses to latitude and longitude and comparing distance between addresses. In this article we look at a simple implementation of a use case involving Geocode that demonstrates how powerful and easy to use the Geocode feature of Salesforce is.

Overview

Through this powerful feature Salesforce can automatically update the “Geocode” information from an address stored in a record. The Geocode consists of three fields: Latitude, Longitude and GeocodeAccuracy. Based on how successful Salesforce is in locating the address, GeocodeAccuracy field is populated. For example if Salesforce is unable to locate the street address specified for the contact, then GeocodeAccuracy will be set to zip, and Latitude and Longitude will be set to the center of zip code area. If GeocodeAccuracy is set to Street, this means that Salesforce was able to locate the street but not the house number. So Latitude and Longitude are set to the midpoint of the street.

Once we have latitude and longitude information as part of the Geocode then we can compare distance between addresses. This leads to many interesting use cases which can be implemented in Salesforce.

This feature is available in Salesforce Professional edition and above. A data.com license is not required to use the Geocode feature. The Geocode feature is also available in Developer edition.

Geolocation field type

In Spring 2015 Salesforce introduced a new structured field type called Geolocation. This compound type includes both latitude and longitude. Appropriate validations are automatically performed on Latitude and Longitude values. Also, Geolocation is a compound data type. In Apex we can access the subfield field using __s suffix. As an example we can use myLocation__latitude__s, where myLocation is a variable of type Geolocation.
We can also create custom fields of Geolocation type.

Clean Rule

The concept of Clean Rule was earlier available in data.com and is now available in Salesforce as well. A Clean rule defines an address field of an object, and maps it to a Geolocation field (which consists of three subfields latitude, longitude and Accuracy). When we define a clean rule we have the option of updating Geocode information for all the records immediately. Clean Rules option is available via Data.com Administration → Clean menu in Setup.

When the Clean Rules are executed, we have the option of skipping execution of triggers, workflow rules and not updating the Last Modified date. Only the Geocode information will be updated in such a scenario.

By default Salesforce includes four Clean Rules:

  1. Billing Address on Accounts
  2. Shipping Address on Accounts
  3. Mailing Address on Contacts
  4. Address on Leads

For each of these we can get Geocode information for all the records. Four Clean Rules corresponding to these four fields are predefined in Salesforce. As an example corresponding to Billing Address on Account, the following fields are defined BillingLatitude, BillingLongitude and BillingGeocodeAccuracy. These get populated using the pre-defined Clean Rule on the Account object.

These rules are disabled by default, and need to be activated before we start using them.
The Geocode fields cannot be added to the page layout. However they can be easily added using formula fields.

Apex Support

Salesforce provides Location class to support Geocode functionality. We can pass latitude and longitude via constructor to create Location object. Once we have Location object we can call getDistance method of Location class to calculate the distance between two Locations. This is explained in detail in standard Salesforce documentation on Location class.

Sample Implementation

Let’s consider the following requirement. Our Sales persons are always on the road. When they visit a customer, they like to find out is there another customer nearby where they can visit for maximum utilization of their time. This scenario can be easily automated using the new Geolocation feature.

We have added a “Get NearBy” button on the detail page of Account record. When the user will click on this record, we will display a list of ten Accounts sorted by distance from the current account. The Salesperson can then decide which customers he will like to visit.

We use the following SQL query to identify the ten closest accounts to the current account:
accList=[SELECT Name,phone,website,BillingStreet,BillingCity,BillingAddress, BillingState, BillingCountry,BillingPostalCode,BillingLatitude,BillingLongitude FROM Account WHERE (BillingLatitude<>null AND BillingLongitude<>null) AND id <> :accID AND BillingState =: acc.BillingState ORDER BY DISTANCE(BillingAddress, :loc , 'mi') asc LIMIT 10];
The above code segment assumes accId, acc and loc are set to the current records Account Id, Account record and Billing Address location respectively.

After the user clicks on the Get Nearby button on Account Detail record, we display the list of ten nearby accounts as shown below:

Salesforce GeoCodes Image1

Another possible use of this feature could be for managing Service visits. For example let’s say in organization JKL Consulting the Service Manager receives request to visit many customers every day. She allocates these customer visits between her Service Agents. This process can be performed in a more transparent and optimal way using the above feature.

Limitations

  1. At this time Geocode Clean Rules are not available in Salesforce Lightning and are available in Salesforce Classic only.
  2. Geocodes do not support Person Accounts at present.
  3. Geocodes do not support Custom Address fields, Custom objects and standard objects other than Accounts, Contacts and Leads.

Summary

Salesforce support for Geocode and related functionality allows developers to map addresses to latitude and longitude. This can then be used to compare distances between addresses. This feature has many applications and can lead to better planning of Sales and Service teams visits to customer locations.