Each account in crm has the default fields address1_latitude and address1_longitude. These fields can be filled manually or via a tool, connecting a service provider like google maps or Bing maps.
With the field service module, you already have Bing maps included. To enable the automatic filling, navigate to Field service > Administration > Field Service Settings. Search for “Auto Geo Code Addresses” and set this to “YES” (the internal name of the field is msdyn_autogeocodeaddresses).
After enabling the Auto Geocode, there will be a popup while entering the address on the account form. The system will offer you possible matches based on the entered address. If you click on one of the offered matches, the latitude and longitude will automatically be filled out.
But what can you do, if you import an account via the API and these fields should also be filled out?
You can create a workflow, which calls the same method, as this method is offered via an action.
Follow these steps:
- Create a workflow that will be triggered on the creation of the account and on the modification of the required fields like street, city, postal code …
Creating a workflow to set the geocode - Add a Step “Perform action” and select the “Resource Scheduling – Geocode Address”. Click on “Set Properties” and define the fields, based on your selected entity. The action requires many fields. If you haven’t all information, you can just put a “-“ in it. Beware, that this might end in a different coordinates, as if you are not providing the street, the coordinates might only be the middle of the provided city.
Required fields of the action - Add an update-step and put in the result of the action and save the account.
Now run your workflow and check, if all is correct.
You might get an error like “Input string was not in a correct format.” Checking the full log shows, that there is a problem with parsing a string to a double.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
Plugin Trace: [Microsoft.Crm.Workflow: Microsoft.Crm.Workflow.Activities.InvokeSdkMessageActivity] [InvokeSdkMessageStep1] [Microsoft.Dynamics.Fps: Microsoft.Dynamics.ScheduleCommon.Fps.FpsPlugin] [c5318cae-a4be-444c-a696-0d2f7eda6d08: Microsoft Dynamics Fps: msdyn_GeocodeAddress (post-operation) for none] FpsPlugin: Webresources Returned from server. Count=1 FpsPlugin: End:RetrieveXmlWebResourceByName , webresourceSchemaName=msdyn_/fps/LocalizationLibrary/LocalizationXml/localizedString.en_US.xml FpsPlugin: End:RetrieveXmlWebResourceByName , webresourceSchemaName=msdyn_/fps/LocalizationLibrary/LocalizationXml/localizedString.en_US.xml FpsPlugin: Settings: Retrieving local FpsPlugin: PluginLocal.Dispose, Depth: 1 FpsPlugin: PluginLocal.Dispose, Depth: 1 FpsPlugin: Input string was not in a correct format. System.FormatException: Input string was not in a correct format. at System.Number.ParseDouble(String value, NumberStyles options, NumberFormatInfo numfmt) at Microsoft.Dynamics.ScheduleCommon.Fps.Actions.GeocodeAddressAction.Maps.GeocodeAddress(String address, Int32 LCID) at Microsoft.Dynamics.ScheduleCommon.Fps.Actions.GeocodeAddressAction.After() at FieldOne.PluginCommon.Operation`1.HandleMessage() at FieldOne.PluginCommon.Operation`1.Execute() at FieldOne.PluginCommon.FosPluginBase.ExecutePlugin(ITracingService tracingService, IPluginExecutionContext pluginContext, IOrganizationServiceFactory serviceFactory) at Microsoft.Dynamics.ScheduleCommon.Fps.FpsPlugin.ExecutePlugin(ITracingService tracingService, IPluginExecutionContext pluginContext, IOrganizationServiceFactory serviceFactory) at FieldOne.PluginCommon.FosPluginBase.Execute(IServiceProvider serviceProvider) FpsPlugin: PluginLocal.Dispose, Depth: 1 FpsPlugin: PluginLocal.Dispose, Depth: 1 Error Message: Unhandled Exception: Microsoft.Xrm.Sdk.InvalidPluginExecutionException: Input string was not in a correct format. |
To fix this issue, you first have to know, how the Bing maps API is working. CRM calls the URL https://dev.virtualearth.net/REST/v1/Locations?q=…&c=….&o=xml&key=……
Parameters:
- q = the street, city, postal code, …
- c = the language code (LCID)
- o = output format
- key = your key that authenticates you
For example:
https://dev.virtualearth.net/REST/v1/Locations?q=4020, Linz&c=1031&o=xml&key=???????
The results looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
<ResourceSets> <ResourceSet> <EstimatedTotal>1</EstimatedTotal> <Resources> <Location> <Name>4020, Austria</Name> <Point> <Latitude>48.287155151367188</Latitude> <Longitude>14.302177429199219</Longitude> </Point> <BoundingBox> <SouthLatitude>48.2530403137207</SouthLatitude> <WestLongitude>14.233360290527344</WestLongitude> <NorthLatitude>48.321331024169922</NorthLatitude> <EastLongitude>14.370510101318359</EastLongitude> </BoundingBox> <EntityType>Postcode1</EntityType> <Address> <AdminDistrict>Upper Austria</AdminDistrict> <AdminDistrict2>Linz</AdminDistrict2> <CountryRegion>Austria</CountryRegion> <FormattedAddress>4020, Austria</FormattedAddress> <Locality>Linz</Locality> <PostalCode>4020</PostalCode> </Address> <Confidence>High</Confidence> <MatchCode>Ambiguous</MatchCode> <GeocodePoint> <Latitude>48.287155151367188</Latitude> <Longitude>14.302177429199219</Longitude> <CalculationMethod>Rooftop</CalculationMethod> <UsageType>Display</UsageType> </GeocodePoint> </Location> </Resources> </ResourceSet> </ResourceSets> |
As you can see, the coordinates are in an English format. The parameter c is used, to put in the language code, but changing this, the result is always the same.
If your Async-User on your backend server is not configured with the culture English, the action can’t convert the coordinates to a valid double. Therefore change the locale of the user to English and the error is fixed and your workflow will work as expected. Also the App-Pool-User on the frontend servers has to use the english format.