Esri Maps for Dynamics CRM - locate workflow cancelled

[GertConradie]

Hi

I'm struggling to find a consistent behaviour on addresses in Ireland.

Note I use Esri Maps for Dynamics CRM version 1.0.1.0 on Dynamics CRM 2011.

Most likely the problem is me, but here are some questions :

1. Would it be possible to see why a locate workflow status end up as 'cancelled'?
2. The geocoding of the same single line address succeeds when submitted via the desktop ArcMap >> Find >> Locations >> "World Geocode Service (ArcGIS online)", but fail in CRM when used as a single line submission against a locate workflow. Should I expect the same result or is this behaviour correct/possible?
3. One can select a country for the workflow - and it seems to affect the accuracy of my results. Unfortunate I can't find this in the design/edit interface of previously created workflows. So it is difficult to confirm if correct. Are this available/visible in the GUI?
4. In the design/edit interface of previously created workflows, the "Esri Maps:Find Location" activity's properties >> address template >> Data Type is "Single Line Of Text", even if the workflow  created with "these columns" and NOT "One Column". Would this affect the geocode result if the workflow was created as 'multi-attribute', but a user enter all information in a single attribute and leave the other attributes empty?
5. Last question (for now) - Are there more detailed documentation available than what one can find here: Spatially enable your data—Esri Maps for Dynamics CRM | ArcGIS

[DanielLee2]

Can you tell me how the address is entered in the address field? Is the address separated with commas? Looks like the geocoding service is having issues parsing the commas. If I enter in the address as a single string without commas, the geocoding is successful. If I try with commas, the geocoding fails (workflow gets canceled). 

[GertConradie]

Hi Daniel

I tried a couple of examples, let's use this for the discussion:

3 Castle Heights, Townspark, Castlepollard, Co. Westmeath

In ArcMap's 'find' I get:

• The right location of type 'StreetAddress', but with a 86% score.
• A type 'AdminPlaces' result, that is the first 100% score.
• other, see screenshot.

In CRM I created two contacts:

• One with the above address in a single line. (street1)
• One with the address split over a couple of fields

In CRM I created two contact workflows: (Disabled for created/update of records, and only triggered manually by myself on the correct records)

• A 'single column' workflow that use (street1)
• A 'multi column' workflow that the correct fields populated in my CRM multiline record.

See the screenshots below. It seems that: (please correct me)

• When no score of 100 can be achieved, then the status is 'cancelled'.
• 'Multi column' workflows cascade up in the accuracy level until a score of 100% is achieved.
• 'Single column' workflows don't cascade up in the accuracy level until a score of 100% is achieved.
• Even though both the single attribute or multi attribute workflows look the same (When the properties are viewed post creation, both indicate 'single line of text') - they in fact differ in behaviour. (I don't know if this difference are how it is submitted, or how the result are cascaded up.)

Any comments regarding detailed documentation, logging or inspecting more detail of the workflow post creation would be much appreciated.

It is clear to me that a location 'fix' solution will need to be available to our client. The data is just to inconsistent in the system & the unpredictability of the geocoding result does not help Is this in the roadmap or is custom development / 3de party solutions the only alternative?

[DanielLee2]

Hi Gert,

You are correct. When no match is found, the process is canceled in Dynamics.  Currently, we do not have any tools to inspect the accuracy rate of a geocode. This is an enhancement that has been requested by others and we will look into implementing it in a future release.  Also, you will get a more accurate result if the address is broken into multiple fields vs a single field.