Microsoft Field Service – Geo-Coding Contact Addresses and Setting Alternative Addresses Geocodes

Posted on: August 2, 2017 | By: Jim Bertler | Microsoft Dynamics CRM

Authored by: Don Surma

Recently, we had a requirement on a CRM Field Service project that involved customization of Field Service for Dynamics 365 CRM. The requirement was to set up Bookings against contacts. In order to get full functionality of Bookings to use the travel time calculation, mapping and directions capability within Bookings, it was important that geocoding was running against contact records.

Out of the box, you have an option under field service to turn on geo-coding. What Microsoft documentation does not make clear is that this runs only against Accounts. You find this out the first time you turn it on, and in a day or two, all of the account address1’s are magically geocoded in the background by the system. Unfortunately, this does not happen to contacts.

The good news is that within the Field Service Module, Microsoft provides a process action in workflows that can be called to geocode any address. When you open workflow steps, this function is available under actions. In practice, you use this action as a step in a workflow, and simply supply the entity address fields, as shown below, that you want to geocode. It places the results into the latitude and longitude fields that are out of box system fields for contacts.

Anyone familiar with using workflows can easily set this up in a few minutes to geocode a contact record upon creation of a new record. One issue is the initial geo-coding of existing records. If the contact record counts are relatively small, say under 10000 records, running a geocode workflow against 500 records at a time is a little time consuming, but can be accomplished in a reasonable amount of time. For anything larger, a custom developed plugin, or a third-party tool such as Scribe are the best options. On this project, the client had nearly ½ million contact records to geo-code. They were already using Scribe online, so we created an update job that triggered the geo-coding workflow against all records that did not have a latitude and longitude data. We scheduled the job run over a weekend, and all exiting contact were geo-coded.

CRM field service

A second requirement for this project was the ability to Schedule Bookings against an alternative address. Often, a booking requires an alternative address in place of their main account or contact address for a meeting. For this requirement, we needed a method to geo-code this alternative address on the fly so it was available to the Field Agent in the specific Booking as the location address. We did not want to change the original Account or Contact Geo-coding.

The out of the box function of creating a booking using the schedule assistant creates a record in the Bookable Resource Booking entity. A close look at the entity form indicated that it contained a longitude and latitude field that held the specific geo-coded address info for the booking. This information is pulled from the Account or contact when the booking is created.

CRM field service

The solution was to add alternative address fields for address name, address1, city state, zip code, and country to the Bookable Resource Bookings form, and set a workflow as described above to pull this data from these alternative fields, and update the geo-code for this booking only. This becomes the new booking location that shows up on mobile devices for the field agent. We used the address name field so the person booking this alternative address could provide a more descriptive location, like “Starbucks”, to provide the field agent a better understanding of the alternative address location.

If you are thinking about using Microsoft Field Service or have questions about configuration, feel free to contact us at Logan Consulting!



2020 Nucleus Research Report on ERP Technology

Free Download:

2020 Nucleus Research Report on ERP Technology

Download the guide ›