Work Order Addressing
By default a work order will inherit it’s address from the service account selected for that work order. This will pull down the address and geospatial information from the account onto the work order.
The geospatial information (longitude and latitude) is critical for a work order, as it drives the location on the map and provides RSO with the information it needs to determine travel times and distances.
Account Addressing
When the Field Service module is installed, it provides auto geospatial coding for address information on out of the box entities. When entering an address on an account record a dialog will appear validating the addresses that match the information the user has selected. By choosing from this list the address information is updated to match, and the longitude and latitude is also set automatically on the Account record.
Work Order Addressing
If the work order needs to occur at a different address to the service account the user can replace the information in the address fields. This will trigger the same dialog mentioned on the account form, to select a valid address, also populating the longitude and latitude.
Bulk Uploads
The problem with the fore-mentioned dialog is it is client side, the same logic does not run automatically on the server side. So if work orders are imported with addresses by bulk from excel or via integration the longitude and latitude will not be set.
This in turn means the system does not know where the job is occurring so it cannot show it on the map, and RSO cannot determine the travel distance and time.
This can be addressed through a workflow that triggers on create and update, Field Service offers a custom action that will use the address information to identify the long and lat, allowing it to be set back on the record. This particular function is available across the system, so it can be used on non-OOB entities, to determine long and lat information.
Resource Starting and End Locations
On a resource record there are settings for where a resource starts and ends their day. This can be their address as recorded in the system (resource address), the address of the organisational unit, or location agnostic (they will start and end their day at the address of the work order).
For the first two it is important we have that addressing information set, otherwise the RSO and Find Availability engines will not be able to determine travel distances and time.
Organisational Unit Address
An organisational unit record does not have separate address information, but it does have a longitude and latitude. As mentioned in the previous section this needs to be set for distance and time calculations.
Out of the box the longitude and latitude fields are not visible on the Organisational Unit form, these need to be added to the form to allow ease of setting. It is unfortunate that out of the box there are not address fields as it means we cannot take advantage of the dialog or the custom workflow activity to find the longitude and latitude.
The only plus around this is organisational units should be a set and forget that do not need to be changed very often.
Resource Schedule Optimisation
The RSO module which auto schedules according to the criteria defined requires long and lat information for work orders, organisational units and resources so it can determine travel times, and distances when determining the best order and allocation of work. A default for the organisation can also be set in regards to how far a person can travel to do the work. This by default is 50km, but for teams that do a lot of travel will need to be increased.
Credit to a Reference
Call back to https://community.dynamics.com/crm/b/crmpowerobjects/archive/2017/04/25/geocode-anything-with-dynamics-365
Talks back to some of the geocoding options and settings.
David Conti 
Recent Comments